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I.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  analysis  was  to  determine  whether  S1000D,  an  international 
specification  for  technical  publications,  should  be  required  in  Department  of  Defense  (DoD) 
acquisitions.  The  Office  of  the  Undersecretary  of  Defense  for  Personnel  and  Readiness  (OUSD 
P&R)  asked  the  Naval  Postgraduate  School  (NPS)  to  weigh  the  arguments  for  and  against 
making  S1000D  a  requirement. 

B.  BACKGROUND 

The  S1000D  specification  was  developed  in  the  1980s  for  civil  aviation  by  the 
AeroSpace  and  Defence  Industries  Association  of  Europe  (ASD).  With  the  growth  of  Integrated 
Logistics  Support  (ILS)  and  Information  Technology  (IT),  the  European  aviation  industry 
developed  a  structured  approach  for  documentation  of  air  vehicle  projects,  resulting  in  S1000D. 
The  most  recent  version,  Issue  4.0.1,  was  released  in  2009  and  was  jointly  produced  by  ASD,  the 
Aerospace  Industries  Association  (AIA),  and  the  Air  Transport  Association  of  America  (ATA). 
In  moving  from  Issue  3.0  to  4.0,  the  specification  extended  beyond  technical  data  to  include 
support  for  learning,  training  and  human  perfonnance  content.  This  version  also  included  a 
number  of  changes  submitted  by  the  U.S.  Anny. 

S1000D  is  the  designation  of  the  International  Specification  for  Technical  Publications 
Utilizing  a  Common  Source  Database  (Issue  4.0.1,  May  12,  2009).  The  S1000D  suite  of 
information  includes  the  technical  publications  specification,  examples  (e.g.,  XML  instance 
documents,  PDF  files,  and  style  sheets),  XML  schemas,  and  any  other  software  or  information 
under  the  heading  “S1000D  suite  of  information”  on  the  pages  titled  “S1000D  On-line”  and 
“Download”  on  the  website  http://www.sl000d.org.  S1000DTM  is  a  trademark  owned  by  ASD. 
Copyright  is  held  by  ASD  and  Ministries  of  Defence  of  the  member  countries  of  ASD.  S1000D 
maintenance  and  evolution  is  governed  by  the  S1000D  Council  and  the  S1000D  Steering 
Committee  made  up  from  members  of  defense  organizations  and  industry.  Recent  history 
includes  (ASD/ATA/AIA,  2009): 
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•  In  2003,  a  Memorandum  of  Understanding  (MOU)  was  signed  between  ASD  and 
AIA  establishing  the  parameters  for  an  agreement  between  the  two  organizations 
hannonizing  US  and  European  guidance  related  to  technical  publications  data. 

•  In  2004,  the  ASD  signed  an  MOU  with  the  US  Advanced  Distributed  Learning 
(ADL)  office.  The  two  organizations  are  working  together  to  harmonize  S1000D 
with  requirements  of  the  Sharable  Content  Object  Reference  Model  (SCORM)  for 
computer-based  training. 

•  In  2005,  a  MOU  was  signed  between  ASD,  AIA,  and  ATA  to  promote  common, 
interoperable,  international  technical  publication  data  in  the  Aerospace  and 
Defense  Industries  and  to  work  in  concert  on  the  joint  development  and 
maintenance  of  S1000D. 

•  In  2007,  the  MOU  between  ASD,  AIA,  and  ATA  was  renewed  to  enable  the  three 
organizations  to  jointly  further  develop,  maintain,  and  promote  S1000D  in  the 
international  arena. 

Over  the  past  several  years,  interest  in  and  application  of  S1000D  have  been  growing  in 
the  US.  Ah  of  the  military  services  (as  well  as  the  US  Coast  Guard)  have  policies  pennitting  the 
use  of  S1000D,  or  are  investigating  policies  regarding  the  use  of  S1000D.  The  standard  is 
currently  being  employed  by  a  number  of  US  DoD  projects,  including:  Air  Force  F-117A  and 
Global  Hawk  unmanned  vehicle  programs,  Naval  Air  Systems  Command  Joint  Strike  Fighter 
program,  Army  Future  Combat  System,  and  the  Naval  Sea  Systems  Littoral  Combat  Ship 
Mission  Module  Program. 

In  2008,  AIA  submitted  a  recommendation  to  the  DoD  to  declare  the  S1000D  standard  to 
be  the  preferred  specification  for  technical  documentation  in  ah  DoD  acquisitions  (AIA,  2008). 
In  response  to  that  recommendation,  OUSD  engaged  LMI  (originally,  the  Logistics  Management 
Institute)  to  assess  the  merits  of  the  AIA  recommendation  to  require  the  use  of  S1000D  (Borek 
and  Wilson,  2008).  According  to  Borek  and  Wilson,  the  DoD  “adopted”  S1000D  on  24  January 
2005  as  an  acquisition  standard,  meaning  it  was  listed  as  an  option,  along  with  several  other 
alternatives,  but  was  not  required.  In  their  analysis,  Borek  and  Wilson  found  that  some  users  of 
S1000D  strongly  favored  it  because  it  “solves  many  problems  associated  with  larger  technical 
documents:  managing  changes,  controlling  versions,  providing  a  framework  for  content 


2 


development,  and  enabling  web-based  and  paper  publishing  formats.”  On  the  other  hand,  Borek 
and  Wilson  suggested  that  some  of  the  benefits  attributed  to  the  use  of  S1000D  actually  derive 
from  the  use  of  a  structured  information  management  solution,  not  necessarily  the  S1000D 
standard  itself.  They  recommended  that  OUSD  (AT&L)  move  forward  in  the  area  of  technical 
publications  by  convening  stakeholder  organizations  to  address  DoD  enterprise  solutions  for 
managing  technical  publications,  identifying  authoritative  data  sources,  and  coordinating  with 
product  lifecycle  management  activities.  According  to  the  recommendations  of  Borek  and 
Wilson,  the  decision  about  whether  to  require  S1000D  should  be  deferred  until  these  enterprise- 
level  issues  are  resolved.  After  the  passage  of  two  years,  during  which  the  use  of  S1000D  has 
grown  in  DoD  and  a  new  version  of  S1000D  (Issue  4.0)  has  been  released,  OUSD  (P&R)  wanted 
to  revisit  the  issue  of  whether  S1000D  should  become  the  required  standard  for  technical 
publication  and  to  support  integration  of  training  and  technical  data.  That  question  was  the 
impetus  for  the  present  analysis  by  the  Naval  Postgraduate  School  (NPS). 
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II.  TECHNICAL  OVERVIEW  OF  S1000D 


A.  STRUCTURED  DATA 

Since  the  early  days  of  computer-generated  documentation,  authors  have  employed 
“mark-up”  or  “tagging”  to  annotate  the  document  content  with  information  used  by  software  for 
formatting  (presentation  in  paper  or  electronic  fonn),  cross-reference  (footnotes,  indexing,  table 
of  contents),  search  (content  description),  document  description  (metadata),  and  other  purposes. 
The  Standard  Generalized  Markup  Language  (SGML)  is  an  international  standard  (International 
Standards  Organization,  ISO  8879:1986)  for  the  definition  of  markup  languages.  Two 
derivatives,  the  Hypertext  Markup  Language  (HTML)  and  the  Extensible  Markup  Language 
(XML),  are  principal  underpinnings  for  the  description  of  content  on  the  World  Wide  Web.  The 
first,  HTML,  largely  provides  a  way  of  describing  how  to  present  document  content  when 
viewed  by  Web  browser  software.  The  second,  XML,  provides  a  way  to  describe  the  content 
itself,  pennitting  greater  automation  in  the  interpretation  and  use  of  information  contained  in 
digital  documents,  and  doing  so  in  a  highly  standardized  way  for  general  applicability  across  all 
computer  systems.  In  contrast  to  HTML,  XML  focuses  on  the  structure  and  content  of  data  as  a 
separate  concern  from  presentation  of  the  data.  Output  formats  of  a  product  can  vary  widely, 
from  printed  media  to  electronic  media  in  a  variety  of  form  factors  (large  screen,  personal  data 
assistant,  cell  phone,  etc.).  In  the  XML  context,  the  document  content  does  not  change  for  each 
different  presentation  style;  rather,  the  style  of  presentation  is  developed  separately  and  as 
appropriate  to  meet  the  needs  of  the  infonnation  consumer.  Apart  from  its  growing  use  in  the 
World  Wide  Web,  XML  is  a  generally  accepted  practice  for  the  description  of  any  data  and  is 
seeing  widespread  use  in  software  applications  across  all  domains. 

The  structure  and  content  of  XML  documents  are  governed  by  an  XML  schema,  itself  an 
XML  document  that  describes  the  structure,  vocabulary,  and  rules  governing  validity  of  data 
values.  With  its  widespread  adoption,  numerous  tools  have  been  developed  in  virtually  all 
computer  environments  and  computer  languages  to  manipulate  XML  documents,  providing 
uniform  ways  for  developers  to  create  and  process  XML  documents.  XML  instance  documents 
that  employ  the  defined  schema  can  be  automatically  validated  against  the  rules  of  the  schema, 
helping  to  reduce  creation  and  proliferation  of  invalid  data. 
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The  S1000D  specification  provides  a  set  of  XML  schemas  to  specify  content  and 
processing  of  technical  publications  confonnant  to  the  specification.  It  is  well  accepted  (and 
corroborated  by  subjects  interviewed  in  this  study)  that  much  of  the  benefit  of  S1000D  comes 
from  its  use  of  XML  as  the  basis  for  describing  data  in  a  standardized,  structured  way. 

B.  DATA  MODULES 

S1000D  discreetly  organizes  information  in  small  files  called  “data  modules.”  The  data 
module  can  support  the  following  types  of  content  and  constructs  (brief  descriptions  are  taken 
from  various  sections  of  the  S1000D  Specification  to  indicate  the  breadth  of  infonnation  that  can 
be  represented  in  the  specification): 

•  Applicability  cross-reference  information  -  Declares  product  attributes.  A 
product  attribute  is  a  property  of  the  product  that  has  an  effect  on  the  applicability 
of  technical  data.  Product  attributes  are  properties  of  the  product  that  are  typically 
set  at  the  time  of  manufacture  of  a  product  instance  and  will  usually  not  change 
throughout  the  service  life  of  a  product  instance.  Examples  of  product  attributes 
are  model,  series,  and  serial  number. 

•  Business  rules  information  -  Identifies  decisions  regarding  the  use  of  S1000D 
for  a  particular  product. 

•  Conditions  cross-reference  information  -  Declares  any  condition  that  can  affect 
applicability  data.  Conditions  can  be  technical,  operational,  environmental,  or  any 
other  type  that  can  affect  technical  data.  Technical  conditions  are  typically  tied  to 
the  configuration  of  the  product.  Examples  of  operational  and  environmental 
conditions  are  location  of  maintenance,  availability  of  tools,  regulatory  rules, 
temperature,  wind  speed,  and  sandy  conditions. 

•  Container  information  -  Provides  a  mechanism  to  associate  several  alternate 
data  modules  representing  the  same  data.  The  container  data  module  helps  to 
maintain  the  consistency  of  links  by  centralizing  the  link  management  and 
providing  the  capability  to  define  the  linking  at  the  source  instead  of  at  the  point 
of  usage. 

•  Crew-operator  information  -  Infonnation  needed  to  provide  ere w/opera tors 
with  the  necessary  degree  of  understanding  of  the  product  and  its  systems  and  the 
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procedures  to  operate  the  product,  its  system  and  equipment  to  their  full  potential 
under  normal  and  failure  modes 

•  Descriptive  information  -  Provides  information  relating  to  paragraph  depth, 
occurrences  of  subparagraphs,  and  use  of  warnings  and  cautions. 

•  Fault  information  -  Captures  and  represents  fault  reporting,  fault  isolation  and 
fault  correlation  information. 

•  Illustrated  Parts  Data  (IPD)  information  -  Captures  and  represents  parts  lists 
and  IPD. 

•  Maintenance  checklists  and  inspections  -  maintenance  planning  information 
that  can  be  used  for  items  such  as  Preventive  Maintenance  Checks  and  Services, 
checking  unpacked  equipment  conditions,  preventive  maintenance  inspection 
forms,  and  criteria  for  special  inspections. 

•  Maintenance  planning  information  -  Identifies  time  limits  (periodicities  and 
life  details  for  a  system),  task  definitions,  inspection  definitions  (groups  of 
maintenance  tasks  or  inspection  types),  and  maintenance  allocation  (maintenance 
functions  along  with  maintenance  levels  and  time  associated  for  each  task). 

•  Procedural  information  -  Captures  and  represents  maintenance  procedural  flow. 

•  Process  information  -  Represents  a  procedural  flow  consisting  of  several  data 
modules  and/or  steps  that  are  sequenced.  Decision  points  (branching),  looping, 
and  selective  filtering  are  supported.  An  interface  to  external  applications  which 
can  return  results  to  direct  procedural  flow  is  supported.  The  process  data  module 
can  be  considered  a  procedural  flow  script. 

•  Products  cross-reference  information  -  A  repository  for  defining  product 
instances  and  associating  values  to  product  attributes  and  conditions  for  each 
product  instance. 

•  Technical  repository  information  -  Identifies  the  use  of  technical  repositories 
for  such  items  as  circuit  breakers,  parts,  zones,  tools,  and  supplies. 

•  Training  information  -  Structures  technical  learning  content  and  configures  it  to 
the  system  for  which  the  instruction  will  be  performed  via  harmonization  with 
SCORM. 
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•  Wiring  data  information  -  Captures  and  represents  the  wiring  data  of  the 
product,  such  as  wire  data,  harness  data,  electrical  equipment  data,  and  standard 
parts  data. 

•  Wiring  data  description  information  -  Defines  the  occurrence,  names,  and 
meanings  of  the  elements  and  attributes  that  are  used  in  the  wiring  data  modules 
(above). 

A  principal  component  in  S1000D  information  management  is  the  Common  Source 
Database  (CSDB).  It  is  an  information  store  and  management  tool  for  all  objects  required  to 
produce  the  technical  publications  within  projects.  Data  modules  stored  in  the  CSDB  are 
available  for  use  by  reference  in  any  number  of  products.  For  example,  in  a  new  version  of  a 
product  line,  a  particular  component  documented  in  a  data  module  may  be  unchanged  and  can  be 
reused  in  the  updated  documentation  for  that  product.  Or,  a  component  used  in  one  product  also 
may  be  used  in  another  product;  the  description  of  that  component  may  not  need  to  change  for 
use  in  the  second  product.  In  these  cases,  the  component  description  has  been  written  and  stored 
once  and  then  used  multiple  times.  Other  benefits  stated  in  the  specification  include 
(ASD/ATA/AIA,  2009): 

•  It  is  based  on  international  neutral  standards. 

•  It  reduces  maintenance  costs  for  technical  infonnation. 

•  It  transforms  data  into  configuration  items. 

•  It  allows  subsets  of  information  to  be  generated  to  meet  specific  user  needs. 

•  It  facilitates  the  transfer  of  information  and  electronic  output  between  disparate 
systems. 

•  Many  different  output  forms  can  be  generated  from  the  same  base  data  thus 
ensuring  safety  of  data  and  that  every  user  regardless  of  output  form  is  getting  the 
same  message. 

•  The  S 1000D  data  module  concept  can  be  applied  to  legacy  data. 

•  It  is  non-proprietary  and  allows  neutral  delivery  of  data  and  management  of  data. 

•  The  specification  incorporates  the  planning  and  management,  production, 
exchange,  distribution  and  use  of  data  in  electronic  fonn  for  different  types  of 
output  (from  page-oriented  to  interactive  electronic  technical  publications). 
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As  will  be  seen  later  in  this  report,  these  statements  are  echoed  in  the  testimony  of  current 
users  of  the  specification. 

C.  SOFTWARE  TOOLS 

A  number  of  commercial  vendors  have  developed  tools  that  produce  SlOOOD-conformant 
documents.  In  addition,  several  DoD  organizations  working  with  S1000D  have  developed 
software  and  tools  that  work  with  S1000D  XML  files.  In  considering  the  question  of  whether  or 
not  DoD  should  require  the  use  of  S1000D,  we  did  not  believe  it  was  in  scope  to  conduct  a 
market  survey  of  products  capable  of  working  with  S1000D,  nor  to  identify  or  endorse  any 
particular  products.  The  important  issue,  we  felt,  was  confirming  whether  suitable  tools  are 
readily  available  to  support  such  a  requirement.  We  are  satisfied  from  our  research  that  there  is  a 
substantial  marketplace  that  has  grown  up  around  the  use  of  the  S1000D  specification,  so  that  a 
decision  to  require  use  of  the  standard  would  be  supported  by  the  availability  of  sufficient  tools. 

D.  BUSINESS  RULES 

From  the  specification: 

Business  rules  are  decisions  that  are  made  by  a  project  or  an  organization  on  how  to 
implement  SI  000D.  Business  rules  cover  all  aspects  of  SI  000D  and  are  not  limited  to 
authoring  or  illustrating.  They  can  also  address  issues  that  are  not  defined  in  SI 000D 
such  as  rules  related  to  how  S1000D  interfaces  with  other  standards,  specification  and 
business  processes  that  are  related  to  its  implementation. 

Application  of  S1000D  to  any  product  development  can  be  tailored  to  the  particular 
needs  of  the  project.  Tailoring  is  performed  by  establishing  a  set  of  business  rules  guiding 
application  of  the  specification  to  the  particular  project.  The  specification  itself  provides  a  large 
number  of  business  rules  that  are  intended  to  be  either  accepted  or  excluded  for  a  particular 
project.  The  specification  identifies  ten  categories  of  business  rules  described  below  (brief 
descriptions  are  taken  from  the  specification  to  indicate  the  breadth  of  coverage  of  the  business 
rules): 

•  General  business  rules  cover  decisions  made  by  a  project  or  an  organization  that 
are  not  covered  by  any  of  the  other  business  rule  categories.  They  serve  as  overall 
decisions  for  the  implementation  of  S1000D.  General  business  rules  include  but 
are  not  limited  to  decisions  about  which  issue  of  S1000D  is  to  be  implemented, 
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identification  of  the  parts  of  S1000D  to  be  used  in  a  project,  and  definition  of 
tenns  used  throughout  the  project. 

•  Product  Definition  business  rules  cover  the  data  module  coding  strategy  related 
to  how  the  product  is  broken  down.  Included  is  the  definition  of  the  model 
identification  codes  to  be  used  in  the  product  and  its  subsystems.  Supplier 
subsystems  and  identifications  also  need  to  be  considered. 

•  Maintenance  Philosophy  and  Concepts  of  Operation  business  rules  cover  the 
types  of  infonnation  that  a  project  or  an  organization  requires.  They  include,  for 
example,  a  list  or  detailed  specification  of  chosen  information  sets,  an  information 
codes  specification  which  details  the  information  codes,  and  information  names 
that  describe  the  data  module  content.  Definition  of  these  rules  must  be  performed 
in  conjunction  with  operation,  maintainability,  repair  and  other  aspects  of 
Logistics  Support  Analysis  (LSA). 

•  Security  business  rules  cover  all  security  issues.  They  include  security 
classifications,  copyright  markings,  use  or  disclosure  restrictions,  destruction 
instructions  and  any  other  data  restrictions. 

•  Business  Process  business  rules  cover  how  technical  publications  development 
is  coordinated  with  other  disciplines  within  an  organization  or  within  the  project 
level  at  that  organization  or  the  project  as  a  whole.  For  example,  they  describe  the 
rules  and  relationships  with  LSA,  S1000M  compliant  initial  provisioning, 
engineering/design,  and  training  (e.g.,  SCORM  compliance). 

•  Data  Creation  business  rules  give  infonnation  about  the  creation  of  text, 
illustrations,  and  multimedia  objects.  Data  creation  business  rules  for  text  include, 
but  are  not  limited  to,  writing  rules,  markup  rules,  and  requirements  for  text 
incorporation  in  multimedia  objects.  Data  creation  business  rules  for  illustrations 
and  multimedia  objects  include,  but  are  not  limited  to,  graphic  style  rules, 
interactivity  detail  rules,  multimedia  format  rules,  and  linking  rules. 

•  Data  Exchange  business  rules  cover  how  data  is  to  be  exchanged  among 
partners  and  customers.  This  includes,  for  example,  the  use  of  data  dispatch  notes, 
how  data  module  requirements  lists  as  well  as  CSDB  status  lists  are  used,  how  the 
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•  Data  Integrity  and  Management  business  rules  enforce  the  referential  integrity 
within  the  CSDB.  The  rules  include,  but  are  not  limited  to,  workflow  business 
rules  (both  internal  and  external)  and  quality  assurance  business  rules. 

•  Legacy  Data  Conversion,  Management,  and  Handling  business  rules  pertain 
to  converting  data  from  some  other  format  to  S1000D  data  modules  (including 
mapping  between  elements  and  attributes  of  source  and  target  specifications,  as 
applicable)  and  rules  for  inclusion  of  legacy  information  in  a  technical 
publication. 

•  Data  Output  business  rules  specify  the  output  formats  for  S1000D  data,  which 
can  include  page-oriented  (e.g.,  paper)  formats,  interactive  electronic  technical 
publication  (IETP)  formats,  multimedia  fonnats,  and  SCORM  formats.  These 
rules  include  decisions  regarding  which  portion  of  the  data  will  be  published  and 
in  what  formats,  and  details  on  how  to  style  element  and  attribute  content. 

Business  rules  are  often  specified  in  “layers”  according  to  the  hierarchy  of  projects  within 
an  organization,  and  organizations  within  a  larger  organization,  to  create  an  overall  enterprise  set 
of  business  rules.  The  number  of  business  rules  grows  as  one  progresses  from  the  highest  layer  to 
the  lowest.  Lower  layers  inherit  business  rules  from  the  higher  layer(s).  The  goal  is  to  minimize 
the  number  of  decisions  made  by  the  author  of  a  publication.  The  practice  of  layering  business 
rules  can  produce  a  tree-like  structure  as  shown  in  Figure  1  (from  the  S1000D  Specification). 
Several  of  the  interview  participants  commented  on  business  rules,  as  given  later  in  this  report. 
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Figure  1.  Example  of  a  defense  tree-like  business  rules  model 


The  Business  Rules  Exchange  (BREX)  data  module  is  a  means  to  communicate  business 
rules  that  have  been  developed  and  agreed  upon  within  a  project  or  organization.  BREX  data 
modules  are  stored  in  the  CSDB.  The  BREX  data  module  can  be  used,  for  example,  to  record 
and  exchange  rules  while  they  are  being  developed  in  a  project  or  organization,  to  support  a 
correct  interpretation  of  the  CSDB  objects,  and  to  enable  validation  of  the  CSDB  objects  against 
agreed  rules.  A  layered  business  rules  structure  can  be  represented  in  a  corresponding  layered 
BREX  data  module  hierarchy. 

E.  S1000D  GOVERNANCE 

S1000D  is  an  international  standard  sponsored  by  several  industry  associations  and 
governed  by  participants  from  a  wide  range  of  backgrounds  and  affiliations.  Refer  to  Figure  2  for 
a  high-level  view  of  the  governing  structure  and  organizational  relationships. 

1.  S1000D  Sponsors 

S1000D  is  developed  and  maintained  by  an  international  community  of  business  and  technical 
experts  from  civil  and  defense  aviation  industries,  as  well  as  from  the  defense  land  and  sea 
industries.  Customers,  suppliers,  and  solution  providers  are  represented.  The  three  sponsoring 
organizations  of  S1000D  are: 

•  Aerospace  and  Defence  Industries  Association  of  Europe  (ASD)  (http://www.asd- 
europe.org) 

•  Aerospace  Industries  Association  (AIA)  (http://www.aia-aerospace.org) 

•  Air  Transport  Association  of  America  (AT  A)  (http://www.airlines.org) 
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S1000D  International  Organization 


Figure  2.  S1000D  International  Organization 

2.  S1000D  Council 

The  S1000D  Council  was  formed  in  accordance  with  a  Memorandum  of  Understanding 
signed  between  ASD,  AIA  and  ATA.  The  main  mission  of  the  Council  is  to  conduct  overall 
governance  of  the  S1000D  development.  The  Council  provides  the  vision  for  the  specification  so 
that  the  mission  can  be  achieved,  together  with  overall  administrative  management  and  direction 
to  the  Steering  Committee  and  general  promotion  of  the  use  of  the  S1000D. 

S1000D  Steering  Committee 

The  S1000D  Steering  Committee  is  a  body  of  members  representing  nations  and 
organizations  who  have  a  common  interest  in  the  specification.  The  Steering  Committee 
maintains  the  currency  of  the  specification  by  processing  Change  Proposal  Forms  and  accepting 
or  rejecting  new  and  changed  material  for  release  in  the  form  of  issues  of  the  specification, 
taking  into  account  the  visionary  direction  of  the  Council. 
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3.  Working  Groups  and  Task  Teams 

Within  the  organization  several  standing  Working  Groups  and  temporary  Task  Teams  are 
formed  to  conduct  the  day-to-day  work  of  developing,  reviewing,  and  managing  changes  to  the 
specification,  XML  schemas,  and  other  associated  products. 
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III.  METHODS 


A.  OVERVIEW 

To  answer  the  question  posed  to  NPS  about  whether  DoD  should  require  the  use  of 
S1000D,  we  pursued  three  main  approaches:  (1)  review  and  analysis  of  documentation;  (2) 
structured  interviews  with  individuals  knowledgeable  and  experienced  in  the  use  of  S1000D;  (3) 
and  a  survey  questionnaire.  The  document  review  fed  into  generation  of  questions  for  the 
structured  interviews,  and  both  the  document  review  and  the  interviews  contributed  to  the 
content  of  the  questionnaire.  The  previous  section  provided  highlights  from  the  document 
review.  The  methods  and  procedures  for  the  interviews  and  the  questionnaire  are  given  here, 
followed  by  the  results  and  discussion. 

Prior  to  recruiting  interviewees  or  participants  for  the  survey,  the  project  investigators 
obtained  NPS  Institutional  Review  Board  (IRB)  approval  for  the  conduct  of  human  subject 
research  in  accordance  with  Department  of  the  Navy  Human  Research  Protection  Program 
policies  and  procedures. 

B.  STRUCTURED  INTERVIEWS 

A  series  of  questions  was  developed  to  capture  information  about  the  nature  of  S1000D, 
the  potential  benefits  or  drawbacks  of  its  use,  and  the  implications  of  a  DoD  decision  to  require 
its  use.  A  copy  of  the  structured  interview  is  given  in  Appendix  A. 

The  structured  interview  included  the  following: 

•  Initial  questions 

o  Basic  demographic  infonnation  (organization,  title,  duties) 
o  Whether  the  interviewee’s  organization  is  currently  using  or  has  used 
S1000D 

•  If  the  interviewee’s  organization  is  using  or  has  used  S1000D,  the  content  of  the 
questions  covered: 

o  What  benefits  were  being  experienced  from  the  use  of  S 1000D 
o  What  expectations  were  not  being  met  from  the  use  of  S 1000D 
o  Estimates  of  costs  and  availability  of  cost  data  from  initial  use  of  S 1000D 
o  Use  of  S 1 000D  for  legacy  systems 
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o  Linkage  with  SCORM  for  training  applications 
o  Would  you  favor  a  DoD  requirement  to  use  S 1000D? 

■  If  yes,  discussion  of  issues  relating  to  implementation  of  the 
requirement 

■  If  no,  does  the  interviewer  prefer  a  different  standard  or  keeping 
the  status  quo,  and/or  discussion  of  what  needs  to  happen  that 
might  change  their  view 

•  If  the  interviewee’s  organization  is  NOT  using  S1000D,  a  different  set  of 
questions  was  asked: 

o  Why  did  your  organization  decide  against  using  S 1000D? 
o  Do  you  plan  to  use  it  in  the  future;  why  or  why  not? 
o  If  yes,  do  you  have  an  estimate  of  the  time  or  cost  to  begin  using  it? 
o  Is  your  technical  data  strategy  based  on  DoD  policy  or  on  internal 
corporate  procedures? 

o  Would  you  favor  a  DoD  requirement  to  use  S 1000D? 

•  Both  sets  of  interviewees,  those  whose  organizations  were  or  were  not  using 
S1000D,  were  asked  this  final  question: 

o  Do  you  believe  that  the  DoD  should  detennine  a  comprehensive 
enterprise-wide  approach  to  product  data  before  making  S1000D  a 
requirement? 

The  project  sponsors  and  supporting  personnel  provided  an  initial  list  of  candidate 
interviewees.  These  were  generally  key  individuals  leading  S1000D  working  groups  or  similar 
organizations.  Also,  because  we  were  seeking  individuals  who  were  knowledgeable  about 
S1000D,  we  identified  candidate  interviewees  from  a  list  of  participants  at  a  recent  S1000D 
user’s  group  conference.  Initial  telephone  conversations  and  subsequent  interviews  contributed 
to  an  expanded  list  of  interview  candidates,  and  so  on.  In  other  words,  we  “bootstrapped”  the  list 
of  interview  candidates  through  an  expanding  network  of  telephone  and  email  contacts.  Because 
this  method  of  developing  candidates  tended  toward  S1000D  supporters,  we  made  proactive 
attempts  to  identify  and  include  individuals  who  were  not  advocates  of  S1000D.  In  short,  our 
interviewees  were  a  “convenience  sample”  drawn  almost  entirely  from  U.S.  sources,  both  DoD 
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organizations  and  industry,  based  on  finding  individuals  who  were  knowledgeable  of  S1000D, 
technical  publication,  and  similar  areas. 

Each  interview  was  conducted  as  a  telephone  conference  call  and  lasted  approximately 
40-60  minutes.  In  a  few  cases,  two  individuals  at  the  same  institution  were  interviewed 
simultaneously.  A  local  company  was  engaged  to  provide  transcription  services.  A  court 
reporter  participated  with  the  interview  team  and  transcribed  the  questions  and  answers.  In  most 
cases,  all  three  authors  participated  in  the  interview;  at  no  time  were  fewer  than  two  of  the 
authors  present.  A  total  of  24  individuals  were  interviewed  in  twenty  interview  sessions. 

C.  SURVEY  QUESTIONNAIRE 

The  survey  questionnaire  was  developed  from  material  obtained  in  the  review  of 
documentation  and  the  telephone  interviews.  We  attempted  to  consolidate  the  issues  into  a  small 
set  of  questions  conveyed  as  Likert  five-point  rating  scales.  A  course  in  survey  methodology  is 
taught  at  NPS  by  Professor  Ron  Fricker  of  the  Operations  Research  Department.  He  generously 
agreed  to  review  and  comment  on  the  draft  questionnaire.  One  objective  was  to  limit  the  time 
required  to  complete  the  questionnaire.  People  frequently  are  asked  to  participate  in  long  and 
tedious  questionnaire  surveys.  We  wanted  to  get  to  the  point  quickly  and  obtain  quantifiable 
data  on  key  questions.  Survey  Monkey  http://www.surveymonkey.com/,  a  web-based  survey 
tool,  was  used  to  create  and  administer  the  questionnaire.  The  first  question  was  used  as  a  filter. 
We  wanted  people  with  some  knowledge  or  experience  with  S1000D  to  participate  in  the  survey. 
The  first  question  asked  how  much  knowledge  or  experience  the  individual  had  with  S1000D.  If 
the  answer  given  was  “Strong”  or  “Medium,”  they  proceeded.  If  the  answer  was  “Weak,”  the 
web-based  survey  branched  to  the  end,  thanking  the  person  for  their  willingness  to  participate. 
The  questions  are  duplicated  in  Appendix  B. 

The  link  to  the  web-based  questionnaire  was  distributed  via  email,  directly  from  the 
authors  to  an  email  merge  list.  The  email  distribution  list  was  developed  with  the  cooperation  of 
a  leader  of  a  S1000D  users  group.  We  added  all  of  the  individuals  on  our  interview  list, 
including  those  who  indicated  an  interest  to  do  the  interview,  but  could  not  be  scheduled  during 
the  time  of  the  study.  At  the  end  of  the  questionnaire,  we  asked  the  participants  to  forward  the 
URL  link  to  anyone  who  was  knowledgeable  about  S1000D.  This  introduced  an  interesting 
aspect  in  that  the  exact  return  rate  cannot  be  determined  because  of  the  networked  nature  of  the 
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invitation  to  participate.  In  any  case,  we  estimate  that  the  size  of  our  initial  distribution  list  was 
approximately  150. 
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IV.  STRUCTURED  INTERVIEW  RESULTS 


A.  SAMPLE  SIZE 

We  conducted  a  total  of  20  interviews  with  a  total  of  24  interviewees.  In  four  of  the 
interviews,  two  subjects  participated  at  the  same  time,  in  accordance  with  their  wishes.  Court 
reporter  services  were  used  to  create  transcripts  of  the  interviews  for  purpose  of  follow-on 
review  and  analysis.  Interviewees  were  from  organizations  across  all  four  military  services,  the 
Coast  Guard,  defense  industry  representatives,  S1000D  product  vendors,  S1000D  governance 
bodies,  and  other  relevant  organizations. 

B,  RESULTS 

In  this  section,  we  provide  a  summary  of  viewpoints  from  the  interviews.  The  section 
includes  numerous  excerpts  from  the  transcripts  to  allow  the  reader  to  “hear”  the  same  things  we 
heard  in  the  interviews.  Excerpts  from  the  transcripts  are  shown  in  italics.  A  minor  amount  of 
editing  has  been  performed  to  enhance  readability.  We  organize  the  findings  from  the  interviews 
into  the  following  categories:  (1)  benefits  experienced  from  using  S1000D;  (2)  challenges  or 
issues  experienced  in  the  use  of  S1000D;  (3)  whether  DoD  should  require  the  use  of  S1000D; 
and  (4)  actions  DoD  must  be  prepared  to  take  if  the  decision  is  made  to  require  the  use  of 
S1000D.  Short  synopses  of  the  comments  from  the  interviews  are  included  in  this  section. 
Additional  interview  material  is  provided  in  Appendix  C. 

1.  Benefits 

•  Reuse  was  one  of  the  primary  benefits  identified  by  interviewees: 

Data  reuse...  it  should  reduce  the  lifecycle  of  that  information  because  you’re  only 
creating  it  once  and  using  it  many  [times] 

...the  basic  business  benefits  ofSIOOOD  would  be  reusability  of  the  information 

...the  pieces  of  information  that  you  create  in  S1000D  are  very  small  pieces  of 
information  that  are  referred  to  as  data  modules.  What  this  means  is  that  these  small 
pieces  of  information  can  be  reused  in  multiple  contexts,  multiple  scenarios 
throughout  a  range  of  systems,  platforms,  or  weapons  systems 

...the  government  is  only  buying  the  data  once  and  not  buying  the  data  6  or  7  times  for 
every  different  end  item  that  the  system  is  going  to  be  used  on. 

The  capability  of  reusing  the  data,  creating  data  once  and  using  it  multiple  times  for 
various  products. 
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The  fact  that  my  systems  change  so  rapidly ,  I  have  to  come  out  with  new  versions  of 
IETMs  on  a  very  rapid,  repeatable  basis.  S1000D  enables  me  to  reuse  the  portions  of 
the  IETMs  that  are  applicable  to  earlier  versions  without  having  to  redevelop  them. 

...that’s  one  of  the  benefits  that  we've  seen,  the  modularity  and  the  reuse  from  some  of 
the  programs. 

...because  the  data  is  broken  down  into  smaller  chunks  of  information  and  we’re  able 
to  reuse  this  information,  that  the  information  is  going  to  be  more  accurate,  the  user  is 
going  to  get  more  timely  changes. 

Once  we  have  it  authored  the  first  time,  we've  verified  it,  we've  made  sure  the 
information  is  correct,  and  then  we'll  be  able  to  reuse  that  over  and  over  again. 

•  A  number  of  interviewees  described  data  exchange  /  data  sharing  as  a  benefit: 

The  benefit  of  the  specification  is  that  it  allows  for  data  exchange  across  platforms  and 
between  companies.  If  companies  are  truly  developing  compliant  S1000  data,  the 
tagging  scheme  within  a  specification  allows  those  parties  to  share  and  reuse  data. 

If  you  tag  the  data  properly  in  one  format,  S1000D,you  can  exchange  information 
with  S3000L,  and  you  can  exchange  information  with  S4000M  and  S5000F. 

It’s  the  data  exchange  and  the  underlying  schemas  and  the  data  type  definitions,  DTDs, 
that  allow  you  to  exchange  across  multiple  IT  systems,  integrated  technology  systems. 

...there  are  definitely  benefits  of  reuse. ...  a  recommended  area  for  further  development 
is  the  data  exchange  between  program  services  and  industry. 

S1000D,  using  the  XML  and  the  tagging  structure,  of  course,  also  lets  you  find  the  data 
more  easily,  as  well  as  being  able  to  use  the  attributes.  So  ...  it  does  make  it  easier  to 
share  information. 

...the  data  sharing  between  the  various  levels  of  maintenance  is  there,  whether  it’s 
organization  or  intermediate  or  depot  or  whatever  it  is,  and  then  also  the  shared  data 
between  U.S.  and  our  foreign  military  customers  as  well  as  shared  data  which  is 
consistently  applied.  ...  if  you’re  using  S1000D,  it  certainly  makes  it  easier  to  share 
data  from  multiple  vendors. ...  keeping  it  in  SI  000D  makes  it  easier  to  share  the  data 
between  vendors  and  with  us. 

•  Several  interviewees  described  real  and  potential  cost  savings  related  to  the 
benefits  cited  above: 

Just  going  to  an  IETM,  we  found  about  a  25  to  28  percent  reduction  in  maintenance 
man-hours  and  a  significant  percentage  in  reduction  of  false  removals. 

We  do  have  the  E-2D,  which  took  the  E-2C  data,  converted  it  to  S1000D  so  that  they 
could  use  it  in  the  D,  and  they  are  finding  a  reduction  of  30  percent,  time  and  cost,  in 
terms  of  updating  the  manuals. 

I  have  a  number  of  circumstances  where  the  implementation  of  SI  000D  has  been 
demonstrated  to  produce  savings,  and  those  savings  vary  in  amounts.  Twenty  to  forty 
percent  are  reported  reasonably  often.  Twenty  percent,  those  figures  are  related  to 
programs  that  are  moving  from  one  as  a  standard  generalized  markup  language,  or 
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XML  kind  of  implementation,  into  SI  OOOD.  Those  don 't  achieve  as  big  a  savings  as 
people  who  are  moving  from  some  unstructured  kinds  of  offering  into  S1000D.  Those 
savings  are  even  greater.  Those  will  approach  the  40  percent,  and  I  have  some 
indications  of  those  kinds  of  savings  from  some  customer  studies  that  have  been  done 
for  several  customers.  There  are  also  some  savings  associated  with  the  production  of 
illustrated  parts  catalogs,  and  those  savings  based  on  implementing  a  relational 
database  for  the  parts  information.  That's  not  required  by  S1000D,  but  is  a  technique 
that's  often  employed.  Those  savings  can  range  from  —  almost  up  to  90  percent,  where 
the  technical  data  has  been  produced  in  a  linear  fashion.  So  that  a  particular  screw  or 
nut,  a  part,  might  be  used  hundreds  of  times  within  a  technical  publication;  and  each 
time  you  would  have  to  specify  all  the  information  about  it  for  procurement.  When  it's 
maintained  in  a  relational  database, you  need  to  specify  that  only  once.  And  it's 
possible  then  to  generate  from  this  relational  parts  information,  the  S1000D 
information.  Those  instances  can  really  provide  substantial  savings,  savings  that  are 
almost  unbelievable.  And  we  have  some  cases  where  this  kind  of  implementation  has 
been  done,  not  because  it  was  required  by  specification,  not  by  law;  nobody  said  you 
had  to  do  this.  We  had  an  oil  pipeline  company  implement  S1000D  simply  as  a  means 
of  improving  their  operation,  and  they  are  the  ones  who  have  reported  this  substantial 
savings  of  90  percent. 

...the  ability  to  reuse  data  and  not  have  to  recreate  data,  on  a  very  small  scale,  has 
saved  me  between  15  and  25  percent  of  my  overall  development  cost.  I  see  that  that 
should  go  up  significantly  once  all  of  my  programs  are  doing  S1000D. 

•  Specific  data  regarding  actual  cost  savings  realized  using  SI  OOOD  were  not 
generally  available  from  the  interviewees.  A  recent  study  for  the  US  Navy 
(Levine,  et  ah,  2010)  examined  potential  cost  savings  for  production  of  technical 
manuals  and  training  courses  while  improving  shipboard  readiness.  The  study 
considers  new  software  and  technical  and  business  procedures  to  integrate  (or 
“Bridge”)  the  production  of  technical  manuals  and  training  courses.  Through  an 
aggregate  analysis  (involving  the  Navy’s  yearly  production  of  Hull,  Mechanical, 
and  Electrical  technical  manuals  produced  by  the  Naval  Ship  System  Engineering 
System  and  all  Computer-Based  Training  courses  delivered  by  the  Naval 
Education  and  Training  Command  Navy  eLearning  organization),  the  study 
found  that  the  “Bridge”  can  achieve  net  benefits  of  $78M  over  10  years.1  A 
second  part  of  the  study,  from  the  perspective  of  a  single  Program  Office  (the 
AN/AQS-20A  mine  hunting  sonar  for  the  Littoral  Combat  Ship),  found  that  the 


1  Levine,  et  al.,  2010,  p  ES-2  and  5-1.  The  study  states  (p  5-2)  that  the  results  depend  strongly  on  several 
uncertain  inputs.  When  variations  on  ranges  of  values  for  those  inputs  are  included,  the  net  benefits  range  from 
$32M  to  $166. 5M  (p  5-4). 
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“Bridge”  can  produce  savings  of  almost  $306K.2  Other  data  across  the  services 
likely  exist  that  can  be  researched  and  included  in  future  cost-benefit  analyses. 
There  is  also  discussion  in  the  S1000D  governing  organizations  about  collection 
and  publication  of  such  data  to  assist  members  and  others  interested  in  the 
standard. 

•  The  availability  and  capabilities  of  tools  operating  on  S1000D  data  were 
highlighted  by  a  number  of  interviewees,  as  well  as  the  openness  of  the  standard: 

Economy  of  scale;  just  have  one  S1000D  tool.  The  tool  that  we  have  provides  the  means 
to  display  multiple  versions  ofSIOOOD  data  modules  at  the  same  time. 

...the  neutral  format  has  allowed  content  to  be  used  in  different  formats.  The  neutral 
format  allows  us  to  use  it  in  different  viewers. 

...the  main  benefit  is  that  the  source  information  in  S1000D  is  created  in  a  completely 
nonproprietary  format. ...also. ..the  specification  ...  is  freely  downloadable  from  the 
internet  and  there’s  no  cost  associated  with  using  the  specification. 

...it  can  be  used  on  multiple  different  software  systems,  multiple  databases  and 
multiple  platforms,  without  having  to  alter  or  modify  the  actual  information  itself,  so 
there’s  no  locking  to  a  particular  software  view  or  platform. 

•  Some  benefits  were  attributed  to  the  nature  of  the  S1000D  specification  itself,  as 
well  as  its  foundation  on  XML: 

The  industry  -  U.S.  industry,  DOD  industry  -  saw  S1000D  as  an  opportunity  to  pick  up 
a  standard  that  was  current,  continually  being  updated. 

...  there  is  no  other  specification  that  exists  that’s  as  well  developed  to  talk  about  how 
to  construct  data  to  produce  technical  publications.  I  believe  the  U.S.  civil  aviation 
industry  has  said  that  now  with  the  incorporation  of  changes  for  Issue  4.1  that  they 
were  ready  to  say  that  they  could  use  that  S1000D  specification  for  all  makes  and 
models  of  civil  aviation. 

I  would  say  different  people  ...  in  different  functional  areas,  including  distance 
learning,  including  acquisition  and  including  logistics  transformation,  have  all  come  to 
the  conclusion  on  their  own  that  S1000D  has  merit  and  that  they  would  invest  in  it. 

And  we  have  made  an  investment  in  trying  to  deliberately  implement  this  program 
within  our  service.  And  everything  so  far  to  date  points  to  the  potential  for  really  great 
benefit. 

Also, ...  because  it’s  being  used  internationally  and  it’s  such  a  supported  standard, 
when  you  come  to  things  like  military  equipment  or  planes  or  any  aerospace  ...  the  tool 
set  is  there,  people  are  trained  up  on  it ...  So  it  just  makes  it  easier.  ...  It  makes  it  a  lot 
simpler  when  you  have  one  standard. 

...it’s  a  consistent  structure  that  seems  to  fit  everything  we  need  to  do. 


2  Op.  cit.,  p  ES-2  and  5-1. 


22 


Doing  technical  manuals,  maintenance  manuals  ...  S1000D  supports  pretty  much  any 
format.  Using  the  description  data  modules;  the  procedure  data  modules ... 
illustrations  ...  we  created  ICNs;  starting  to  use  some  of  the  process  logic  modules  in 
data  modules 

S1000D  has  been  used  in  Europe  for  20  years.  It’s  not  something  new  and  bleeding 
edge.  It’s  new  to  us.  But  there  are  a  lot  of  people  out  there  that  have  a  lot  of  experience 
with  it  and  can  help  in  these  projects. 

•  Integration  of  training  into  S1000D  content  has  been  a  recent  addition  to  the 
specification  that  is  highly  valued  by  a  number  of  interviewees: 

S1000D I  think  is  the  first  technical  data  standard  that  addresses  the  integration 
between  the  IETM  tech  data  community  and  the  E-learning  and  training  content 
community.  ...  S1000D  provides  a  mechanism  of  sharing  the  data  so  you  can  have 
common  illustrations  between  the  learning  content  and  the  technical  content.  You  can 
have  common  text  and  common  theory  of  operations  and  system  descriptions  between 
the  technical  data  and  the  training  content. 

Integrate  the  production  of  technical  manuals  and  training  courses...  with  integration, 
there  will  be  a  reduction  in  the  cost  of  producing  future  tech  manuals  and  then 
training  courses...  the  integration  would  reduce  the  possible  incidence  of  disparate 
information  given  in  technical  manuals  and  training  courses 

...integration  may  speed  up  the  production  of  technical  manuals  and  training  courses, 
and  therefore  that  may  reduce  the  possibility  -  or  give  some  insurance  against  the 
possibility  of  lags  in  the  fielding  of  new  systems  and  equipment  upgrades,  and  the 
delivery  of  up-to-date  technical  manuals  and  training  courses  to  the  fleet.  ...the 
benefits  in  terms  of  reduction  in  future  costs  far  outweigh  the  investment  and 
implementation  costs. 

...it’s  a  lot  easier  to  understand  how  a  system  is  put  together.  ...  I  see  the  training 
aspect  as  a  major,  major  plus. 

...the  4.0  version  ofSIOOOD  does  give  you  the  framework  in  order  to  do  that.  It 
provides  the  learning  side  of  SI  000D.  So  I  can  put  in  all  of  my  standard  learning 
content. ..it  provides  the  framework  for  someone  on  the  outside,  whether  it’s  the 
database  person  or  someone  else,  to  say  "If  you  give  me  this  information  I  can  create  a 
SCORM  package  for  you." 

We  found  that  we  can  at  least  make  sure  the  training  people  know  when  the  data 
changes,  because  that’s  been  a  big  disconnect...  for  the  training  data,  keep  it  more  in 
synch  with  the  actual  equipment  and  the  manuals. 

Our  SI  000D  information  set  uses  a  job  duty  task  structure.  We  did  that  before  SI  000D 
really  started  embracing  training,  so  we  haven’t  started  out  with  what  the  S1000D 
spec  offers  for  training  reuse,  but  we’re  definitely  in  support  of  that  and  trying  to 
support  it  technically  with  how  we’re  going  to  implement  S1000D. 
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2.  Challenges  and  Issues 

•  Use  of  S1000D  brings  a  number  of  technical  and  programmatic  challenges. 
Several  interviewees  commented  on  the  need  for  leadership,  policy,  transition 
support,  and  comprehensive  vision: 

Policy  has  not  caught  up  with  use.... 

Without  OSD  or  DOD  policy,  programs  can  choose  not  to  implement  the  specification. 
There’s  nothing  saying  that  they  should  look  at  it. 

What  we  in  the  industry  have  run  into  is  that  when  we  get  to  a  certain  level  of 
leadership  within  the  services,  the  lack  of  understanding  or  knowledge  of  the 
specification  and  what  it  can  do  has  hindered  that  policy  decision. 

...historically  when  we  issue  a  standard,  we  just  throw  it  out  there  and  have  the  folks 
use  it.  We  have  also  identified  supporting  documentation  such  as  handbooks  and  rules 
checkers,  business  rules  that  are  used  to  implement  SI  000D.  We've  got  that  all 
identified  and  started  and  put  into  place  before  the  programs  were  able  to  use  S1000D. 

A  lot  of  times  the  decision  is  made  to  go  with  S1000D  when  we  don't  even  know 
whether  or  not  we  can  use  the  data  that’s  produced  or  what  we  would  have  to  do  to  it. 

[regarding  S-series  specifications]  ...one  of  the  challenges  is  to  figure  out  how  all  those 
specs  could  be  mingled  together  to  do  cross-disciplinary  storage  ofILS  data,  to  see  how 
that  data  can  all  be  integrated  together.  That’s  obviously  something  that’s  being 
explored  right  now  at  the  international  level.  ...  We  have  so  many  standards  already  in 
the  US  for  a  lot  of  these  things.  Figuring  out  how  or  when  or  if  we  migrate  to  any  of 
those  other  standards  is  a  bit  of  a  question  mark. 

Within  the  Army,  there’s  absolutely  no  interest  in  talking  about  training  being 
standardized  and  using  S1000D  to  author  training  and  store  training  or  anything  like 
that.  In  fact,  there’s  just  very  little  effort  going  on  for  them  to  integrate  training  with 
any  spec  or  standard  in  a  meaningful  way.  ...  So  there’s  this  big  hole  for  what  goes  on 
with  training  and  the  integration  of  training  and  tech  publications  and  S1000D,just 
because  there’s  not  the  right  organizations  to  respond  to  it. ...  as  much  as  it  may  seem 
like  an  OSD  ATL  effort,  I  think  if  you  really  look  into  it,  it’s  not  including  most  of  the 
services  in  any  meaningful  way. 

•  The  cost  in  staffing,  training,  and  tool  support  can  be  an  issue  in  moving  to  the 
S1000D: 

[There  is]  definitely  a  ramp-up  cost  to  support  the  conversion  or  the  transition  over  to 
an  S1000D  implementation.  [There  is  a]  learning  curve,  and  we  lack  of  project  business 
rules.  There’s  probably  a  lack  of  data  module  coding  strategy...  but  the  big  one  is  the 
learning  curve  and  the  business  process  piece. 

...like  all  standards,  you  need  to  make  an  investment  upfront  to  move  to  that 
standard... 
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It  does  require  an  investment  in  personnel,  training,  and  infrastructure,  because  it’s  a 
very  advanced  information  process  and  it’s  not  until  later  on  down  the  line  you  start  to 
realize  those  benefits.  Like  all  content  reuse  standards,  the  payoff  comes  downstream. 

There  needs  to  be  infrastructure  in  place  to  be  successful,  and  that  is  IT  infrastructure, 
software  tools,  and  personnel  and  training...  that’s  probably  the  biggest  challenge 
facing  an  organization  that  is  looking  at  adopting  SI  OOOD. 

There  is  definitely  a  learning  curve  with  S1000D.  It’s  a  very  big  document,  it’s  a 
process,  and  it’s  a  standard  of  handling  tech  data  that’s  different  than  what  programs 
are  used  to  doing. 

...if you've  ever  looked  at  the  specification,  it’s  about  3,000  pages  long.  3,000  pages 
long  puts  a  lot  of  people  off.  They  don’t  want  to  deal  with  that.  They  think  this  thing  is 
way  too  hard,  who  would  want  to  go  there.  But  in  reality,  if  you  build  tech  manuals  for 
a  living,  it’s  really  a  blessing  because  the  answer  is  in  there.  Everything  has  been 
thought  through.  And  if  the  answer  is  not  there,  then  the  way  to  ask  the  question  is 
there,  [other  standards]  ...  a  lot  of  times  the  tagging  structures  are  there,  but  they’re 
not  clearly  defined.  So  you  really  don’t  have  consistency,  you  don’t  have  interpretation 
being  the  same.  So  that's  why  I  really  like  SI  OOOD ...  it  was  a  lot  of  information,  but  I 
did  definitely  find  clearly  defined  structure. 

...the  downside  is  there’s  a  lot  of  up-front  work  in  terms  of  developing  the  business 
rules... 

...that’s  where  we  struggled  internally  quite  a  bit,  was  as  we  established  these  business 
rules  and  made  the  interpretation  of  what  the  spec  was  telling  us ...  what  does  this 
mean  and  what’s  its  applicability  in  these  particular  cases?  But  once  we  got  there,  then 
the  actual  effort  required  to  begin  to  produce  data  and  get  product  became  all  that 
much  more  efficient  for  us. 

The  objection  [to  adoption]  I  hear  most  often  is  the  overhead,  this  whole  need  to  fill  out 
all  of  this  information  about  the  information,  about  data. 

•  Some  interviewees  expressed  concern  about  the  rapid  change  in  the  standard  over 

the  past  several  years: 

The  specification  has  been  changing  at  a  very  rapid  rate  in  the  last  few  years... the 
scope  is  expanding  too  fast  to  keep  up 

Multiple  versions  -  the  UK  is  just  going  to  switch  up  to  2.3 

...it's  no  sooner  you  get  done  with  determining  what  your  higher-level  business  rules 
are  for  one  issue,  then  the  next  issue  comes  out  and  you’ve  got  to  go  back  in  and 
revisit. ..figure  out  where  all  the  decision  points  are.  You’ve  got  that  with  any  spec,  it’s 
just  we’ve  made  it  a  more  formalized  process  with  S1000D. 

S1000D  has  been  written  so  as  to  be  appropriate  for  the  military,  and  up  until  about 
issue  2.2  there  was  no  interest  in  commercial  aviation.  With  issue  3.0  we  included  a  lot 
of  stuff  for  the  commercial  environment,  stuff  that  I  think  the  military  is  better  off 
without.  But  it  was  all  added  as  optional  components.  So  you  don’t  have  to  buy  into 
those  optional  components,  but  they  are  available.  And  so  I  think  that  this  whole 
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business  then  of  going  through  the  specification  and  deciding  which  components  of  it 
are  going  to  be  most  suited,  provides  some  difficulty. 

•  One  interviewee  indicated  success  in  working  with  S1000D  inside  his/her  own 
organization,  but  sees  challenges  ahead  in  working  across  programs  and 
organizations: 

We've  selected  a  tool  set,  we've  developed  business  rules,  and  we  have  style  sheets  or 
schemas  that  the  program  is  using.  Where  you  start  -  or  where  I  anticipate  having 
some  difficulties  or  possibly  some  issues  is  when  we  start  interfacing  with  other 
programs  or  other  communities. 

•  Some  interviewees  see  limitations  in  the  standard  (at  least,  with  respect  to  the 
version  they  are  currently  using)  or  employment  of  the  standard: 

From  a  program  perspective,  1  could  envision  reducing  my  costs  if  I’m  developing 
products  for  training  and  for  IETMs  at  the  same  time  or  very  closely  in  tandem.  The 
specification  doesn’t  allow  me  to  do  that  today. 

...the  drawback  today  is  that  the  way  the  spec  is  written,  it  doesn’t  do  everything  it’s 
purported  to  be. 

Individual  interpretations  of  the  standard  lead  to  confusion  sometimes,  and  inaccurate 
data. 

The  biggest  issue  we  have,  [is  that]  you  can’t  really  print  a  full-out  manual  with 
SI  000D...  it’s  not  impossible  to  do,  but  it’s  harder  to  do. 

...the  business  rules,  and  then  the  printed  output  is  a  challenge...  The  other  challenge  is 
the  electronic  display  of  large  wiring  diagrams. 

[SI  000D  is  an]  International  specification,  so  you  may  not  necessarily  get  what  you 
ask  for  and  either  have  to  rework  stuff  or  you  have  to  conform  to  the  spec... 

Some  of  the  up-front  work  demanded  by  the  use  ofSIOOOD  is  the  establishment  of 
business  rules.  Several  interviewees  described  challenges  in  this  regard  (although, 
sometimes  leading  to  positive  outcomes  in  the  end): 

Their  design  decisions...  aren’t  really  conducive  to  understanding.  There  are  very  short, 
nondescriptive  element  names.  You  basically  need  their  2,000-page  spec  to  understand 
what  the  XML  is  supposed  to  be  representing,  whereas  with  some  vocabularies  it’s  very 
obvious  what  the  XML  is  representing,  [coming  from  a  more  descriptive  XML]  ...you  are 
losing  some  of  the  semantics’  robustness.  When  people,  even  S1000D  proponents,  did 
an  evaluation  of  our  schema,  they  decided  it  was  not  a  business  case  for  us  to  move  to 
S1000D.  Some  even  said  it  would  be  a  step  backwards  because  of  the  robustness  of  our 
own  vocabulary  and  the  tools  around  it.  S1000D  is  using  very  generic  and  sometimes 
very  cryptic  names  for  their  elements.  Some  of  their  naming  or  some  of  the  new 
elements  [in  Issue  4.0]  are  certainly  more  descriptive  than  in  version  3.  There's  a 
significant  loss  in  meaning  when  you  go  from  our  vocabulary  to  SI  000D. 

Some  of  the  element  names,  just  very  short  abbreviations,  looks  like  they  came  from 
table  headers  from  20  years  ago;  they  really  are  not  following  ISO  111  79,  for  example, 
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which  is  what  most  best  practices  use  for  naming  data  items. ...  They  don’t  do  that.  So 
it  makes  it  a  lot  more  difficult  to  try  to  understand  the  XML  when  looking  at  it.  ...  a 
result  of  having  the  separate  schemas,  sometimes  they  have  the  same  element  name  in 
two  different  schemas,  but  their  content  is  different.  So  that’s  something  else  that 
makes  a  learning  curve  a  lot  more  difficult.  That  makes  the  translator  more 
complicated,  because  you  can’t  use  the  same  process  for  one  type  of  document  that  you 
can  for  the  other,  because  there’s  inconsistency  in  their  definitions. 

3.  Should  S1000D  be  a  DoD  Requirement? 

•  There  was  wide  diversity  in  responses  to  this  fundamental  question.  While 
generally  positive  about  potential  benefits  of  S1000D  (see  above),  many 
interviewees  were  cautious  in  their  response  to  this  question,  expressing  concern 
about  the  notion  of  a  mandated  standard  that  would  be  applied  across  the  board, 
especially  to  legacy  systems,  without  concern  for  business  case  or  cost: 

...such  a  requirement  would  make  sense  for  all  new  systems. ..by  mandating  or 
requiring  that  with  the  new  systems,  what  the  DoD  is  doing  is  they’re  setting 
themselves  up  for  success  in  the  future. 

...why  not  start  today  and  why  not  start  with  S1000D 

...at  this  point,  probably  not...  You  could  mandate  it  for  new  system.  I  think  that  would 
be  more  of  a  logical  step  as  far  as  mandating  anything.  Mandating  for  legacy  systems 
is  going  to  be  a  big  price  tag  that  they’re  not  going  to  be  able  to  pay  for. 

After  a  while,  you’re  going  to  see  more  and  more  programs  using  it,  and  at  that  time,  I 
think  it  would  be  very  sensible  to  mandate  something  like  this. 

The  mandate  -  the  mandate  is  harsh.  Guidance,  yes,  you  should  look  into  it  and  see  if  it 
makes  sense. 

Enthusiastic  "yes." 

I  have  a  problem  with  "required, "  because  there’s  always  that  legacy  issue.  If  you’re 
building  something  new,  you’re  always  going  to  go  back  and  you’re  going  to  be  using 
some  existing  information,  some  existing  equipment.  The  Navy  has  the  same  electronic 
warfare  system  on  all  its  airplanes,  or  the  IFF. ..are you  going  to  require  that  vendor  to 
change  the  way  they’re  doing  business  just  because  you  want  to  put  them  in  SI  000D 
format?  ...there’s  policy  that  needs  to  be  written,  there's  guidelines  that  need  to  be  in 
there,  but  to  mandate  everything  is  overkill. 

If  I  were  doing  it  today,  from  an  OSD  perspective,  I’d  make  it  [required]  for  all  new 
acquisitions  regardless  of  size.  ...Most  programs  today  are  going  to  have  some  sort  of 
electronic  data  system,  and  if  you’re  doing  that,  then  why  not  do  an  IETM  based  on 
S1000D? 

I  would  almost  hate  to  say  required  because  there  is  a  cost  involved,  and  you  are 
taking  some  of  the  decisions  away  from  the  Program  Manager.  So  who  knows  what  the 
constraints  are  going  to  be  within  that  project?  I  think  that  there  has  to  be  a  lot  of 
qualifiers  on  that  statement. 
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We  have  been  working  with  it.  We  have  a  production  department  set  up  to  do  it.  ... 
From  a  general  perspective,  from  a  larger  perspective,  1  think  that  it  would  be 
beneficial  for  the  DOD  to  have  one  schema  ...  to  have  a  common  schema  that  is  used  for 
all  of  their  technical  data. 

I  think  S1000D  is  only  applicable  to  fairly  complex,  large,  high-value  end  items. 

Yes,  for  standardization  and  more  priority  for  funding  to  go  forward  with  the  S1000D. 

•  Some  interviewees  believe  S1000D  is  already  an  ad  hoc  standard  and  will 
continue  to  grow  in  application  across  DoD,  even  without  it  being  made  a 
requirement: 

I  would  be  in  favor  of  it  [making  S1000D  a  requirement].  Is  it  absolutely  necessary?  No. 
I  think  programs  are  starting  to  see  it.  I  think  the  programs  are  starting  to  do  it  on 
their  own  because  it  does  make  sense. 

I  have  always  felt  like  the  market  will  make  or  break  this  thing.  So  if  it’s  sensible  to  use 
S1000D,  everybody’s  going  to  use  it  anyway  and  there’s  really  no  purpose  in  requiring 
anybody  to  do  it. ...  by  the  time  you  try  to  get  into  all  the  nitnoid  details  of  what’s  really 
required  in  a  mandate, you  may  as  well  be  letting  the  programs  decide  themselves.  It’s 
either  going  to  be  sensible  for  them  or  it’s  not,  and  ultimately  what  it  boils  down  to  is 
that  a  program  is  going  to  do  what  they  want  to  do  anyway,  because  they’re  in  a 
separate  funding  stream  from  anything  anyone  has  any  control  over.  There's  not  so 
many  new  [DoD]  programs,  and  I  think  SI  000D  is  already  out  there  and  everyone’s 
already  -  the  OEMs  are  putting  in  the  support  for  S1000D  because  it’s  sensible  for 
them,  and  when  they  go  to  bid  on  a  new  weapons  system,  they’re  just  going  to  bid 
S1000D  because  [they]  want  to  use  their  existing  tools..  I  just  think  it’s  going  to  work 
itself  out  as  it  should  in  the  free  market. 

{ S1000D ]  is  going  to  be  the  answer,  when  they’re  trying  to  figure  out  which  spec  to 
use...  it  will  be  obvious  when  they  get  there.  And  the  more  tools  there  are,  the  more 
programs  will  be  using  it,  the  more  resources  that  learn  it  and  are  comfortable  with  it, 
the  more  international  tools  that  are  built,  the  more  cool  tools  that  are  built  to  support 
specific  business  processes  by  the  services.  All  of  that  is  just  going  to  make  people  move 
to  SI  000 D. 

Regardless  of  whether  or  not  OSD  has  made  { S1000D ]  a  mandate,  it  looks  to  us  like  it 
makes  real  sense  to  use  this  standard.  Programs  are  going  to  go  there  anyway,  only 
because  either  there  isn’t  anything  better.  ...  it  makes  it  better  or  easier  for  programs 
to  just  have  someone  else  make  some  of  these  kinds  of  decisions  for  them,  so  they  can 
start  focusing  more  on  specifics. 

•  Interviewees  also  provided  their  opinions  about  waiting  to  make  S1000D  a 
requirement  in  order  to  focus  first  on  establishing  an  enterprise-wide  approach  to 
the  management  of  technical  data: 

We  don’t  want  to  wait.  This  is  something  that  should  occur  simultaneously,  so  that  the 
enterprise-wide  approach  can  evolve  using  best  practices  from  those  programs  with  a 
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head  start ,  while  launching  the  S1000D  requirement  to  be  phased  in  using  logical 
steps. 

There  is  great  benefit  to  be  realized  by  coming  up  with  an  enterprise  architecture.... 
[before  S1000D  being  mandated?]  No.  ...it’s  a  piece  of  it,  and  if  you  do  it  that  way,  in 
pieces  where  you  can  manage  it,  it  makes  it  much  easier  than  trying  to  do  it  all  at  once. 
You’ve  got  to  mandate  it  with  the  enterprise  architecture  plan  in  mind. 

The  data  requirements  are  built  in  CDRLS,  and  they’re  kind  of  antiquated.  ...the  real 
challenge  is  that  this  is  really  a  text  document  and  publication  standard  which  if 
implemented  would  yield  some  operational  efficiencies  within  the  publications 
organizations,  but  it’s  thought  that  it  probably  would  do  that  at  the  expense  of  the 
maintenance  community  that  they  are  servicing,  and  for  the  reasons  that  were  noted 
in  the  document  [previous  LMI  study]  ...the  purpose  of  it  is  to  reuse  content.  ...they 
want  to  create  an  environment  where  they  are  not  just  reproducing  chapters  in  books, 
but  reproducing  content  and  sentences  ...  and  they  want  to  do  this  in  a  way  that  allows 
them  to  always  maintain  relevance  of  the  information  that  is  in  the  document  to  the 
specific  activity  that’s  being  performed 

We  need  data  standards  that  say  this  is  what  the  data  is  and  this  is  exactly  what  it 
needs  and  how  you  interpret  it.  So  if  we  can  look  at  SI  OOOD  as  being  part  of  that 
enterprise  of  data  standards,  not  enterprise  of  applications,  then  that’s  what  I'm  for... 
If  we  can  define  how  the  data  goes  together  in  the  enterprise  for  the  whole  life  cycle, 
then  we  win. 

There  should  be  a  collaboration  [between  DoD  and  industry]  ...  but  I’m  not  sure  that 
that  would  be  the  determining  factor  on  whether  to  require  the  use  of  SI  OOOD  or  not. 

•  Some  interviewees  did  not  believe  S 1000D  should  be  required: 

/  would  recommend  a  DOD  endorsement  of  the  spec,  not  necessarily  a  mandate....  and 
then  each  service  and  each  organization  would  have  to  decide  for  themselves  if  they 
want  to  endorse  it  across  their  organizations  or  whether  they  just  want  to  just  allow  it 
as  an  option. 

Before  I  would  recommend  it  becoming  a  requirement,  I  would  again  make  sure  it  does 
everything  that  we  think  it  is  going  to  do. 

Requirement?  No.  Definitely,  without  a  doubt,  no.  [S1000D]  is  not  something  that  I 
think  is  yet  to  the  point  where  somebody  should  consider  it  becoming  a  requirement.  It 
would  indeed  be  a  step  back  for  me  ifl  was  required  to  use  S1000D.  There’d  be  a  lot  of 
costs  of  investing  in  new  tools,  learning  curve,  training  -  and  all  for  no  added 
functionality,  and  actually  some  loss  in  the  meaningfulness  of  the  vocabulary.  It  would 
be  a  step  backwards  as  far  as  functionality,  as  far  as  potential  use  of  the  data,  as  far  as 
automated  evaluation  of  the  data.  It  would  all  be  for  naught  —  all  the  effort  we’ve  put 
into  creating  a  schema  that  follows  all  of  the  Department  of  the  Navy  naming  and 
design  rules  and  ISO  standards.  [IfSIOOOD  were  required,]  we  would  be  moving  to  a 
vocabulary  that  didn’t  do  all  those  things. 

Explain  in  great  detail  what  is  the  value  proposition  ofSIOOOD.Where  are  the 
economies  associated  with  this  standard,  and  what  needs  to  be  suboptimized  in  order 
to  achieve  those  efficiencies? ...  My  suspicion  is  that  there  is  suboptimization  in  the 
development  of  the  maintenance  systems  associated  with  the  standard.  ...articulate 
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the  value  of  SI  OOODfrom  the  perspective  of  the  end-user  [edge  maintainer  in  the  case 
of  maintenance].  There  may  be  better  ways  to  achieve  that  objective  if  you  make  the 
assumption  that  there  are  no  economies  associated  with  S1000D.  ...  If  there  is 
[negative]  impact  to  the  semantic  relevance  of  the  actual  maintenance  activities  being 
performed  at  the  edge  because  you  have  done  this  [adopted  S1000D],  then  where  is 
your  advantage? ...  you  might  as  well  go  with  a  best  in  class  commercial  tool.  Who 
manages  the  common  object  repository?  ...the  TechDoc  and  publications  community? 

If  so,  then  how  do  you  maintain  it  in  terms  of  work  flow  and  ensuring  change 
management  and  control,  etc? 

If  you  have  a  business  case  for  moving  to  it,  if  there  are  advantages  in  your  program 
for  moving  to  SI  OOOD,  then  certainly,  go  for  it.  But,  include  some  of  the  caveats  in  the 
NAVSEA  guides -  "Well,  you  can  use  it;  but  if  you  do,  make  sure  that  these  things  hold, 
that  you  have  the  necessary  expertise,  that  you  assume  any  added  risks  or  costs."  Make 
sure  you  have  the  necessary  expertise.  Otherwise,  it’s  going  to  be  increased  cost  in 
getting  the  expertise.  And  you  have  to  assume  also  the  added  risks:  the  risk  being 
maybe  a  delay  in  delivery  while  people  are  getting  up  to  speed  with  the  specification, 
and  certainly  increased  upfront  costs.  But  for  someone  who  already  has  a  working 
vocabulary,  an  XML  vocabulary  that  is  generally  considered  to  be  a  quality  vocabulary 
and  follows  all  the  best  practices  and  policies,  procedures  and  ISO  specifications,  [Yes, 
go  ahead  and  use  it].  But,  I  don’t  think  it  would  be  in  the  best  interests  of  the  DOD  to 
force  them  to  move  to  SI  OOOD.  Generally  speaking,  I  think  that  if  the  policy  were  to 
produce  SI  OOOD  compliance  from  whatever  vocabulary  you  are  developing, ...  I  would 
certainly  have  less  a  problem  than  an  outright  mandate  for  people  to  develop  in 
S1000D. 

[S1000D]  would  still  have  to  evolve  to  a  point  where  everyone  is  being  cognizant  of 
best  practices,  again,  such  as  ISO  naming  conventions,  more  meaningful  element 
names,  being  able  to  capture  some  semantics  better  than  they  currently  are,  as  well  as 
consistencies  between  their  schemas. 

Everything  that  we  do,  whether  it  is  in  OSD  or  in  industry,  should  be  backed  up  by  a 
solid  business  case.  I  think  there  is  a  pretty  solid  business  case  to  use  SI  OOOD  for  new 
programs,  and  for  those  programs  going  through  midlife  update  or  modernization. 

But,  make  that  decision  on  a  business  case  basis,  rather  than  mandate  it.  The  problem 
with  a  mandate  is  that  people  follow  it  blindly,  and  it  might  not  necessarily  be  the  most 
sensible  or  cost  effective  decision  to  simply  blindly  follow  a  mandate. 

4.  DoD  Actions  Needed  to  Promote  Successful  Implementation  of 
S1000D 

Simply  making  SI  OOOD  a  requirement  will  not  necessarily  result  in  successful 
implementation.  The  success  of  using  SI  OOOD  is  likely  to  hinge  on  the  vision, 
commitment,  leadership,  and  actions  by  DoD  management.  Interviewees 
identified  a  number  of  actions  that  DoD  ought  to  perform  so  that  SI  OOOD  can  be 
implemented  successfully: 

/  would  like  to  see  some  kind  of  a  policy  statement  from  DOD.  If  it's  not  a  requirement 
to  use  SI  OOOD  for  this  category  of  items,  maybe  it  is  something  along  the  lines  of 
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NAVAIR’s  [guidelines].  With  that,  you  could  get  some  of  these  other  DOD  entities  to 
develop  more  standards  for  the  specific  tools,  and  we  could  share  licenses,  you  would 
get  more  bang  for  your  buck.  And  it  would  support  the  decision  to  require  use  of  the 
specification.  If  it  became  much  more  cost  effective  and  you  saw  all  these  other 
benefits,  [it  becomes]  a  no-  brainer. 

Funding  is  needed  to  transition  [to  S1000D], 

More  support  from  OSD  for  the  use  [ofSIOOOD]  would  be  as  appropriate,  but  even 
more  appropriate  would  be  more  involvement  [of  DoD]  on  the  international  side  with 
AIA,  as  opposed  to  just  a  mandate  to  us  to  use  it. 

[DoD  should]  institute  some  kind  of  training  course,  maybe  through  the  Defense 
Acquisition  University.  If  a  standard  is  going  to  be  required  and  its  use  his  going  to  be 
far-reaching  within  the  DOD  and  have  implications  for  the  next  20  or  30  years,  I 
believe  that  good  training  on  the  use  of  that  standard  [is  essential].  Likewise,  for 
things  like  the  business  case  of  when  to  convert,  and  also  the  associated  "S"  series 
standards,  which  may  have  value  to  a  project,  all  of  those  topics  should  be  trained, 
perhaps  through  the  DAU.  [This  training  should]  be  made  available  to  the  prime 
contractors  and  OEMs  and  members  of  the  different  services  that  are  going  to  be 
involved  in  acquisition  programs. 

...you  have  got  to  have  a  comprehensive  methodology  for  managing  the  asset  class  as 
you’re  taking  it  to  fight.  And  so  the  government  has  a  certain  amount  of  obligation  to 
own  and  maintain  and  invest  in  that. 

You  need  to  have  a  more  holistic  approach  to  developing  these  sophisticated 
maintenance  management  tools,  and  it  involves  a  lot  of  different  parties  that  need  to 
be  brought  to  the  table  as  part  of  a  common  enterprise. 

•  The  DoD  policy  would  need  to  clearly  distinguish  between  a  requirement  for  new 

systems  and  its  application  to  legacy  systems: 

If  you’re  doing  something  new,  go  ahead  and  use  SI  000D.  If  you  are  a  legacy  program 
that  has  a  legacy  system  in  place,  consider  a  migration  path,  but  there’s  no  reason  for 
you  to  stop  the  presses  and  switch  courses  midstream 

...there  should  be  a  business  case  analysis  for  any  project  that  is  less  than  five  years 
[duration] 

I  think  that  the  suite  of ’’S’’  standards  should  be  looked  at  for  anything  that  has  major 
modifications  to  it  in  the  future,  or  any  new  weapons  platforms,  which  probably  won’t 
be  many  for  the  next  few  years. 

But  the  business  case  tells  me  if  I’ve  got  5  years  left  on  a  weapons  platform  that  I’m 
going  to  migrate  all  my  data,  there’s  no  return  on  investment.  That’s  why  the  business 
case  should  be  performed,  to  show  if  there  is  a  return  on  investment  or  not. 

...if  it  [legacy  system]  was  going  to  be  phased  out  in  5 years,  there’s  probably  no  benefit 
in  converting  that  data  to  S1000D.  If  the  system  had  a  service  life  of,  say,  20  more 
years,  then  there's  probably  a  good  case  for  converting  that  data  to  SI  000D. 
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•  Interviewees  also  made  an  appeal  for  senior  DoD  to  take  a  leadership  role  in 
working  groups  and  governing  bodies  responsible  for  maintenance  and  evolution 
of  the  S1000D  standard: 

Most  of  the  services,  independent  of  a  DOD  mandate,  are  developing  their  own 
acquisition  policy  and  guidelines  for  S1000D  information  now,  and  they’re 
collaborating  ...  at  a  multi-service  level.  What  we  don’t  have  yet  is  top-down 
coordination  at  the  DoD  level.  I  think  that’s  something  that  we  need,  and  I  think  it’s 
something  that  would  be  extremely  welcome  from  the  Joint  Services. 

Currently,  within  the  S1000D  organization  there  is  a  group  called  USSMG,  United 
States  Specification  Management  Group,  which  is  part  of  the  big  overarching 
leadership  group  for  SI  000D.  Technically,  OSD  has  a  spot  as  the  co-chair  of  that  group. 
That  spot  has  been  filled  on  an  ad  hoc  basis  by  a  rotating  —  an  Air  Force  rep,  an  Army 
rep,  a  Navy  rep,  over  the  last  8 years.  But  we  really  don 't  have  the  authority  to  say, 
yeah,  this  is  what  OSD  or  DOD  says.  And  if  they  could  get  involved  in  that  group  and  do 
those  things,  from  our  point,  that  would  help. 

What  the  industry  has  struggled  with,  is  that  there  are  committees  that  both  have 
industry  representation  and  leadership  as  well  as  slots  for  Department  of  Defense  and 
OSD  leadership  within  those  organizations,  working  groups,  etc.  for  the  S1000  work. 
And  those  DoD  or  OSD  positions  have  basically  been  held  temporarily  by  individuals, 
but  no  formal  appointment  has  been  assigned  for  those  services  or  OSD.  ...we  have  no 
concurrence  from  the  Government  in  those  positions,  whether  they  represent  the  entire 
DoD,  OSD,  or  they  represent  their  service. 

We  have  members  from  all  the  services  that  are  either  working  or  they  have 
subcontractors  working  for  the  services,  actually  writing  out  the  change  proposals, 
sitting  in  on  committees,  traveling  to  some  of  the  committee  meetings  to  incorporate 
the  service’s  requirements  into  the  specification. ...  The  problem  that  we've  had  in 
industry  is  that,  because  of  changes  in  the  administrations  and  changes  in  leadership 
at  OSD,  once  it  looks  like  we  get  our  foot  in  the  door  and  get  a  name,  that  person 
moves  on. 

[DoD/industry  collaboration  on  an  enterprise-wide  approach]...I  believe  that  this  is 
happening  right  now...  the  Joint  Services  IETM  working  group  ...  is  trying  to 
standardize  wherever  possible  on  technical  data  requirements  from  a  multi-service 
perspective.  There’s  no  reason  why  OSD  or  DoD  couldn’t  or  shouldn’t  have  a  seat  at 
that  table  and  perhaps  be  the  authority  that  the  Joint  Services  IETM  working  group 
reports  to. 

When  it  comes  to  a  battle  on  changes  [to  S1000D],  if  we  had  somebody  [at  the  DoD 
level],  I  think  it  would  resonate  a  little  more  with  the  international  community  that 
we're  a  little  more  serious  about  it. 

...it  would  be  great  if  the  DOD  increased  its  presence  [in  the  international  S1000D 
organization]...  to  be  able  to  be  in  that  community,  to  learn  from  it,  to  gain  insight 
would  be  valuable. 

The  immediate  primary  need  is  that  DOD  needs  to  have  somebody  involved  at  the 
North  American  level  [USSMG]  on  the  committee  to  work  alongside  industry  at  that 
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level  and  establish  some  real  basis  for  DOD  business  rules...  There’s  never  really  been 
anybody  appointed  at  the  DOD,  a  representative  overall  to  the  international  S1000D 
community.  ...  the  largest  problem  right  now  is  the  coordination  across  all  these  DOD 
organizations  as  far  as  business  rules,  and  there’s  a  lot  of  disparity  in  people’s  beliefs 
as  to  what  level  of  control  should  be  exercised  from  the  top-down.  ...  the  coordination 
through  the  groups  moving  vertically  from  the  top  down  needs  to  be  there,  with  the 
appropriate  levels  of  control 

At  the  enterprise  level,  you  ought  to  be  able  to  share  your  meta  data  so  I  can  know  that 
you’re  writing  this  kind  of  content  based  on  the  information  code,  and  1  can  look  and 
see  it’s  going  to  be  released  on  this  date,  it’s  going  to  be  this  hardware,  the  other 
information,  and  plan  whether  I'm  going  to  reuse  that  content.  And  once  I  can  find  it, 
then  what’s  the  mechanism  to  get  a  copy  of  it  or  point  to  it  or  borrow  it?  How  do  I  do 
that?  Take  it  in  steps;  have  the  meta  data  library  initially  and  then  find  a  way  to 
develop  collaboratively. 

•  Another  key  activity  for  top-level  coordination  is  in  the  establishment  of 
organization-wide  business  rules: 

If  you  had  an  OSD  set  of  SI  000  business  rules,  it  would  really  work.  At  the  top  you 
would  have  the  OSD  set  of  business  rules,  and  then  that  gets  handed  down  to  the 
services.  And  the  services  may  have  some  unique  requirements  for  their  platforms,  so 
they  modify  those  business  rules,  and  then  they  pass  it  down  to  the  program.  And  the 
program  may  have  a  modification  that  they  may  be  tightening  the  specification 
requirements  you  have,  not  loosening  them  up. 

Mandating  [the  use  ofSIOOOD]  is  okay  if  you've  got  your  ducks  in  a  row...  if  you  have  a 
set  of  government  business  rules.  The  higher  level  business  rules  really  put  the 
structure  around  what  the  government’s  looking  for,  and  then  the  services  can  tighten 
those  up,  not  loosen  them  up,  tighten  them  up,  for  the  programs  and  for  their  services. 

Typically,  I  would  expect  to  see  DoD-level  rules,  service-  level  rules,  then  project-  level 
rules. 

Step  in  and  take  ownership  [of  joint  service  business  rules],  because  there’s  actually  no 
way  for  us  to  publish  these  business  rules.  We  have  no  resources  to  do  that  for  joint 
services.  So  currently  all  the  services  are  publishing  joint  service  rules,  with  a  little 
marker  in  their  own  service  business  rules. 

Industry  and  government  need  to  consult.  And  unfortunately,  I  think  the  current 
branches  of  the  DOD  need  to  consult  and  see  if  they  can’t  bring  these  things  nearer  to 
the  same.  SI  000D  has  quite  a  bit  of  flexibility  within  it,  and  in  some  cases  the  flexibility 
that  is  allowable  is  being  made  differently  between  the  services;  and  that  is  going  to 
lead  to  not  achieving  as  much  efficiency  as  could  be  achieved. 

I  think  that  the  DOD  would  be  best  served  if  there  were  a  Department  of  Defense  set  of 
business  rules  that  made  that  specification.  Look  at  and  establish  that  DOD  set  of 
business  rules  that  all  of  the  services  would  be  required  to  adhere  to. 

Will  we  be  doomed  to  failure  without  DOD  arbitration  across  services  on  [SI  000D] 
business  rules?  No.  I  believe  that  there  still  will  be  substantial  benefit  because  the 
organization  of  the  information  will  be  consistent.  It’s  not  [consistent]  today.  And 
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that  consistency  has,  I  think,  a  considerable  value  in  and  of  itself.  I  think  the 
maintenance  of  the  information  will  be  lower  for  military  kinds  of  equipment  because 
the  data  is  in  smaller  chunks. 

The  only  thing  we  need  is  the  top  level  business  rules  for  DOD  to  be  basically  sanctified, 
because  a  lot  of  things  are  being  handled  at  the  lower  levels  because  there  is  no  policy 
at  the  top  level. 

[The  business  rules]  are  the  decision  points.  There  are  business  rules  at  certain  levels 
that  we  know  are  joint  service  business  rules.  They  just  need  to  be  officially 
[acknowledged]  as  the  rules  of  DOD. ...  It  would  be  a  tiered  environment.  There  are 
hundreds  of  decision  points  in  S1000D,  but  there  are  some  that  should  be  common  to 
all  of  the  services,  and  then  you  break  it  down  to  service-level  business  rules,  then 
within  the  Navy  you  have  the  NAVSEA  business  rules,  then  you  would  have  Panama 
City  business  rules,  and  then  you  would  have  the  last  few  of  them  are  the  project  rules. 
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V.  QUESTIONNAIRE  SURVEY  RESULTS 


A.  SAMPLE  SIZE  AND  SOURCE 

Responses  to  the  survey  were  received  from  180  individuals  during  the  three-week  period 
that  it  was  available  at  the  designated  web  site.  The  first  question  asked  for  a  self-rating  of 
knowledge  of  S1000D.  The  response  options  were  “Strong,”  “Marginal,”  and  “Weak.”  Only  8 
of  the  180  indicated  that  they  had  “Weak”  knowledge  of  S1000D.  Those  8  were  re-routed  to  the 
end  of  the  survey  and  thanked  for  their  participation,  leaving  172  respondents  who  provided  data 
on  the  survey.  Because  of  the  nature  of  recruiting  participants  for  web-based  surveys,  it  is  not 
possible  to  calculate  a  return  rate.  Nevertheless,  the  authors  felt  that  a  sample  size  of  172  was 
excellent  and  certainly  sufficient  to  support  any  statistical  testing,  as  needed.  Figure  3  shows  the 
distribution  of  representatives  whose  professional  experience  was  associated  with  the  various 
military  services,  either  as  a  Government  representative  or  industry. 


My  professional  experience  is  associated  primarily  with: 


m  U.S.  Army 

U.S.  Navy/Marine  Corps 
U.S.  Air  Force 
U.S.  Coast  Guard 
IB  Other  (please  specify) 


Figure  3.  Distribution  of  questionnaire  participants  by  service 

The  Navy/Marine  Corps  was  the  largest  group,  representing  43%  of  the  total,  followed  by 
“Other”  at  27%,  the  Air  Force  with  21%,  and  the  Army  and  Coast  Guard  with  approximately  5% 
each.  A  wide  range  of  affiliations  was  provided  in  the  “other/specify”  category,  including  some 
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with  multiple  or  “all”  service  affiliation,  general  DoD  contractor,  and  some  non-US  affiliation 
including  UK  Ministry  of  Defence,  German  Air  Force,  and  Australia. 

B.  RESULTS 

Most  of  the  questions  in  the  survey  were  framed  as  a  five-choice  rating:  “Strongly 
Agree,”  “Agree,”  “Disagree,”  “Strongly  Disagree,”  and  “Don’t  Know/  No  Opinion.”  For 
purposes  of  data  analysis,  we  combined  the  Strongly  Agree  and  Agree  into  one  category. 

1.  Benefits 

The  following  question  was  asked  regarding  expected  benefits:  “From  your  experience, 
which  of  the  following  benefits  do  you  believe  are  likely  to  be  realized  with  S1000D?”  In 
response,  84%  of  the  respondents  agreed  that  there  would  be  “Efficiencies  from  ‘Reuse”  of 
Data.”  Furthermore,  74%  agreed  that  there  would  be  benefits  from  S1000D  in  the  area  of  “Links 
between  logistics/technical  data  and  training  (SCORM).”  In  short,  there  was  very  strong 
agreement  among  the  172  respondents  regarding  these  two  expected  benefits  from  the  use  of 
S1000D. 

The  open-ended  question  at  the  end  of  the  “Benefits”  section  requested  the  respondents  to 
specify  other  expected  benefits  from  the  use  of  S1000D.  A  total  of  71  respondents  offered 
comments  regarding  potential  benefits.  These  comments  are  reproduced  in  Appendix  D.  In 
general,  the  potential  benefit  most  commonly  mentioned  was  standardization  across  systems  and 
military  services.  Potential  cost  savings  also  was  mentioned  frequently  as  an  expected  benefit 
from  the  use  of  S 1000D. 

2.  Key  Question:  Should  S1000D  be  Required? 

In  response  to  this  key  question,  Table  1  shows  the  percentages  of  respondents  who 
agreed  that  S1000D  should  be  required  in  the  three  categories  indicated. 


DoD  Should  Require  S1000D  for: 

Agree  or 

Strongly  Agree 

ALL  DoD  systems? 

40.6% 

New  Acquisitions  but  not  legacy? 

62.7% 

Large  (CAT  I/II)  but  not  small  Acquisitions? 

51.3% 

Table  1.  Percentage  who  Agree  with  three  levels  of  Requirement:  All  Systems;  New 

versus  Legacy;  Large  versus  Small  Acquisition. 
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Despite  the  long  list  of  potential  benefits  mentioned  above  and  listed  in  Appendix  D,  less 
than  a  majority  (40.6%)  felt  that  S1000D  should  be  mandated  for  all  DoD  systems.  On  the  other 
hand,  a  substantial  majority,  (62.7%)  agreed  that  S1000D  should  be  required  for  all  new 
acquisitions.  Two  interpretations  can  be  made  of  these  data:  (1)  the  expectation  of  benefits 
from  the  use  of  S1000D  does  not  necessarily  justify  making  it  a  requirement  for  all  systems;  and 
(2)  there  is  strong  support  for  requiring  S1000D  for  new  acquisitions,  but  not  for  legacy  systems. 
This  latter  point  also  was  discussed  in  the  interviews,  discussed  previously,  where  several 
participants  suggested  that  legacy  systems  should  not  be  transitioned  to  S1000D  unless  they  were 
expected  to  have  a  long  life  cycle  remaining,  i.e.,  the  “business  case”  must  support  the  decision 
to  apply  S1000D  to  a  legacy  system. 

Follow-up  questions  were  asked  in  the  questionnaire  regarding  the  core  issue  of  whether 
S1000D  should  be  required  by  DoD.  The  results  of  those  questions  are  shown  in  Table  2. 


In  my  opinion,  DoD  should: 

Agree  or 
Strongly  Agree 

Allow  Program  Managers  to  decide  whether  to  require 
S1000D 

44.1% 

Allow  each  Service  to  establish  policy  on  whether  to 
require  S1000D 

43.4% 

Promote  and  encourage  the  use  of  S100D  but  NOT 
require  it 

47.4% 

Require  S1000D  but  allow  an  "opt  out"  if  the  business 
case  is  not  supported  for  specific  program  or  system 

75.6% 

Table  2.  Percentage  of  respondents  agreeing  with  statements  of  potential  DoD  policies 

on  S1000D 

None  of  the  first  three  options  garnered  a  majority  in  agreement.  But,  whatever  the 
lingering  doubts  about  requiring  S1000D,  they  seemed  to  be  substantially  reduced  by  allowing 
the  possibility  of  an  “opt  out”  when  the  business  case  is  not  supported. 

In  the  end,  we  can  assume  that  all  parties  share  the  same  goals  of  increased  efficiency  and 
accuracy  in  developing  technical  data  and  publications.  This  set  of  questions  supports  that 
notion,  because  it  avoids  the  threat  of  mandating  the  use  of  S1000D  in  cases  where,  for  any 
reason,  it  would  not  be  cost  effective.  The  unstated  assumption  underlying  this  issue,  however, 
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is  that  all  parties  can  agree  on  a  process  for  performing  an  analysis  of  the  business  case  and  agree 
on  the  criteria  for  when  it  has  been  “made”  or  “not  made.” 

3.  Potential  Drawbacks 

In  the  search  for  a  balanced  approach  to  understanding  the  benefits  and  drawbacks  of 
S1000D,  a  set  of  questions  was  developed  to  elicit  opinions  about  potential  downsides.  Table  3 
provides  the  percentage  of  respondents  who  agreed  with  each  item. 


Please  rate  your  agreement  with  the  following  items: 

Agree  or 
Strongly 
Agree 

Software  tools  for  implementing  S1000D  can  create 
incompatibilities 

60.0% 

S1000D  is  changing  rapidly;  let's  wait  until  it  becomes  more  stable 

28.4% 

The  DoD  should  avoid  using  a  Standard  that  is  controlled  by  an 
International  body 

20.3% 

DoD  has  not  sufficiently  investigated  the  adoption  of  the  entire 
"S-series"  of  Standards 

37.7% 

Table  3.  Percentage  of  respondents  in  agreement  with  the  listed  risks  or  downsides 

The  survey  participants  exceeded  a  majority  in  agreement  on  only  the  first  issue  - 
incompatibilities  can  result  from  S1000D  software  tools.  This  was  a  relatively  strong  response 
(60.0%)  and  warrants  further  analysis.  Perhaps  DoD  should  consider  ways  to  promote 
compatibility  among  software  tools  supporting  S1000D.  Incompatibilities  caused  by  the  vendor- 
specific  tools  seem  to  be  at  odds  with  the  core  intent  of  standardization  to  promote  reuse  and 
interoperability. 

4.  Contributing  Activities  by  DoD 

In  a  number  of  the  interviews,  participants  stated  that  active  participation  by  DoD  will  be 
crucial  to  achieve  the  intended  benefits  from  the  use  of  S1000D.  Simply  requiring  its  use  will 
not  be  enough.  This  set  of  survey  questions  attempted  to  identify  potential  DoD  activities  that 
would  increase  the  likelihood  that  the  S1000D  requirement  will  have  the  intended  benefits. 
Table  4  provides  a  summary  of  the  results  of  these  questions. 
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Some  people  feel  that  DoD  should  participate 
more  vigorously  in  activities  related  to  the 
management  of  technical  data.  Please  indicate 
your  agreement  with  the  following  potential  DoD/ 
OSD  activities 

Agree  or 

Strongly  Agree 

Promote  an  enterprise-wide  solution  to  managing 
technical  data 

84.5% 

Advertise  and  promote  the  use  of  S1000D 

81.9% 

Participate  actively  in  S1000D  international  policy 
boards 

88.4% 

Provide  funding  for  training  and  transition  to 
S1000D  usage 

87.2% 

Promote  the  consistency  and  compatibility  of 
S1000D  Business  Rules  (BREX)  across  services 

89.6% 

Table  4.  Percentage  of  respondents  who  agree  with  various  roles  and  activities  by  DoD 

This  set  of  questions  may  be  the  most  important  in  the  survey.  A  very  strong  majority 
(>80%)  of  the  respondents  agreed  with  all  five  items  in  this  category.  The  two  highest  rates  of 
agreement  (88%  and  90%)  were  (1)  the  DoD  should  participate  actively  in  policy  boards 
governing  S1000D,  and  (2)  the  DoD  should  promote  the  consistency  and  compatibility  of 
S1000D  business  rules  across  services.  Collectively,  this  set  of  questions  can  be  taken  as  a  plea 
for  help  or,  perhaps,  a  call  for  leadership.  Simply  requiring  the  use  of  S1000D  is  not  enough. 
DoD  is  being  requested  to  take  an  active  leadership  role  in  developing  an  enterprise-wide 
solution,  advertising  and  promoting  that  solution,  providing  funds  for  training  and  transition, 
taking  an  active  role  in  the  international  governance  of  the  S1000D  standard,  and  ensuring  that 
implementation  of  S1000D  via  “Business  Rules”  is  consistent  across  services. 
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VI.  RECOMMENDATIONS 


Based  on  the  information  and  opinions  gathered  from  nearly  200  participants  in  the  study, 
we  conclude  that  S1000D  should  be  a  required  standard  for  technical  publications  across  the 
DoD.  This  action  should  be  taken  in  conjunction  with  a  program  to  implement,  transition,  and 
promote  its  success.  This  program  would  include  a  set  of  critical  provisions  for  DoD  to:  (1) 
manage/govern  the  use  of  the  standard;  (2)  promote  the  use  of  the  standard;  (3)  support  adoption 
and  evolution  of  the  standard;  and  (4)  establish  and  enforce  use  of  the  standard. 

Specifically,  we  recommend  the  following: 

1.  Require  the  use  of  S1000D  for  new  acquisitions  unless  the  business  case  clearly 
shows  otherwise  (e.g.,  possibly  in  the  case  of  a  very  small,  one-off  item). 

2.  Require  the  use  of  S1000D  for  legacy  systems  only  when  a  business  case  (cost- 
benefit  analysis)  supports  its  use  for  a  specific  program  or  system. 

3.  Establish  a  DoD  Technical  Information  Governance  Office  to  provide  top-level, 
enterprise-wide  leadership  and  guidance  for  technical  publications  and  technical 
data  across  acquisition,  logistics,  maintenance,  training,  and  other  relevant 
endeavors.  This  enterprise-level  view  should  include  evaluation  of  the  full  S- 
Series  family  of  specifications  with  a  vision  toward  fully  integrated  technical  data 
across  the  system  lifecycle. 

4.  Actively  participate  in  the  S1000D  governing  organizations  to  act  as  a  proponent 
for  the  technical  and  business  interests  of  DoD  agencies,  organizations,  and 
component  services.  Applicable  S1000D  organizations  include  the  S1000D 
Defense  Working  Group,  the  S1000D  Steering  Committee,  the  S1000D  Council, 
and  the  Joint  Service  IETM  Technology  Working  Group. 

5.  Develop  a  plan  for  transition  and  introduction  of  S1000D  across  the  DoD 
including  responsibility  for  training  acquisition  personnel  and  program  managers 
in  the  S1000D  standard. 

6.  Develop  Department-level  business  rules  and  coordinate  creation  of  layered 
business  rules  across  the  Services  and  DoD  agencies  and  organizations. 
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7.  Monitor,  evaluate,  and  establish  requirements,  as  necessary,  to  ensure 
compatibility  of  commercial  and  open  source  tools  for  production  of  S1000D- 
compliant  publications  and  courses  among  the  Services,  organizations,  programs, 
and  systems  using  the  standard. 

8.  Make  the  financial  commitment  to  support  the  transition  to  the  use  of  the  S1000D 
standard  throughout  the  DoD.  Supportive  efforts  should  include  assisting  in  cost 
benefit  analyses,  training  and  education  of  acquisition  and  management 
personnel,  and  guidance  for  legacy  conversion  (in  cases  when  such  conversion  is 
deemed  beneficial). 

9.  Require  S1000D  format  for  ah  interchange,  reuse,  and  storage  of  technical 
publication  data  and  technical  training  content,  while  allowing  and  encouraging 
innovation  in  different  approaches  (fonnats,  tools,  etc.)  at  the  authoring  level. 
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APPENDIX  A  -  STRUCTURED  INTERVIEW 


S1000D  Study  Data  Collection  Instructions  and  Scripts 

[Instructions  to  researcher:  The  following  is  a  script  for  use  in  a  recruitment  e-mail  or 
for  recruitment  over  the  phone.  It  is  followed  by  a  script  for  introducing  the  study  questions  and 
obtaining  the  subject ’s  consent  to  participate,  notification  that  the  interview  is  being  recorded, 
and  subject’s  decision  to  allow  or  disallow  attribution  of  comments .] 

[Researcher  and  study  introduction ] 

Hello _ .  My  name  is _ .  I  am  on  the  research  faculty  of 

the  Naval  Postgraduate  School  in  Monterey,  California.  We  have  been  tasked  by  the  Office  of 
the  Under  Secretary  of  Defense,  to  conduct  a  study  investigating  the  potential  benefits  and 
challenges  of  promoting  the  S1000D  International  Specification  for  Technical  Publications  as  a 
required  standard  for  Department  of  Defense  acquisitions.  We  are  seeking  expert  perspectives 
from  government  and  industry  and  would  like  to  invite  you  to  contribute  to  the  study  by 
participating  in  a  [structured  interview  /  survey].  It  will  take  approximately  50  minutes  to 
complete  the  interview. 

Do  you  have  any  questions?  [deal  with  any  questions  the  subject  may  have ] 

[Inform  the  subject  of  the  procedures,  subject ’s  rights,  and  obtain  consent.  ] 

Did  you  receive  the  consent  form  that  we  sent  you  and  have  you  had  a  chance  to  review 
that  form? 

We  want  to  remind  you  that  your  participation  in  this  study  is  strictly  voluntary.  You  can 
change  your  mind  at  any  time  and  withdraw  from  the  study.  There  are  no  negative  consequences 
if  you  choose  not  to  participate  or  to  withdraw. 

We  will  record  your  name,  organization,  e-mail  address,  and  phone  number  for  our 
records.  All  personal  identifiable  infonnation  will  be  protected  and  only  used  in  study 
publications  by  your  approval.  You  may  choose  to  allow  any  information  you  provide  us  to  be 
attributable  to  you  by  name  and  organization,  or  you  may  choose  to  disallow  attribution.  You 
may  also  change  your  decision  at  any  point  during  the  interview. 

Do  you  have  any  questions  at  this  time?  [deal  with  any  questions  the  subject  may  have ] 
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At  this  time,  we  will  begin  recording  this  interview  for  the  record.  We  have  hired  the 
services  of  a  local  company  to  create  a  transcript  of  this  interview.  The  transcript  will  be  used 
solely  for  data  collection  and  analysis  purposes. 

For  the  record,  your  name  is _ . 

You  work  for _ .  [ organization/company ] 

You  are _ .  [title/rank] 

If  you  consent  to  be  identified  by  name  in  this  study,  any  reference  to,  or  quotes  used 
from  the  transcript  will  be  published  in  the  final  research  finding  only  after  your  review  and 
approval.  If  you  do  not  agree,  then  you  will  be  identified  broadly  by  position  or  title  (for 
example,  “V.P.  Logistics”).  Again,  you  may  change  your  decision  at  any  time  during  the 
interview  on  individual  questions  and  answers. 

Do  you  consent  to  have  your  statements  be  identified  by  name  and  organization? 

Thank  you. 

Do  you  have  any  questions  before  we  proceed?  [ deal  with  any  questions  the  subject  may 

have] 

[Research  Questions] 

Does  your  program  or  organization  use  S1000D?  [if  yes,  proceed  with  the  questions 
below;  if  no,  jump  to  the  next  set  of  questions] 

If  yes,  you  are  using  S1000D: 

1 .  What  benefits  are  you  experiencing  from  using  S 1000D? 

a.  Are  you  experiencing  benefits  in  reuse  from  using  S1000D? 

b.  Are  you  experiencing  benefits  in  system  interoperability  from  using 
S1000D? 

c.  Are  you  experiencing  benefits  in  information  sharing  from  using  S 1000D? 

d.  Are  you  experiencing  benefits  in  lifecycle  management  from  using 
S1000D? 

e.  Are  you  experiencing  benefits  in  system  acquisition  from  using  S 1000D? 

f.  What  expectations  are  not  being  met  from  the  use  of  S 1000D? 

i.  Why  are  they  not  being  met? 
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2.  Are  you  collecting  any  cost  or  perfonnance  data  in  the  use  of  S 1000D? 

a.  What  do  the  numbers  indicate? 

3.  Have  you  used  S 1000D  to  convert  technical  data  on  legacy  systems? 

a.  In  your  experience,  what  was  the  cost  to  convert  legacy  technical  manuals 
to  S1000D? 

b.  How  long  did  it  take  to  convert  the  data  to  S1000D? 

c.  Were  all  legacy  materials  able  to  be  converted  or  were  there  materials  that 
could  not  be  converted  to  S1000D? 

4.  For  what  types  of  technical  data  are  you  using  S 1000D? 

5.  What  components  of  the  S 1000D  specification  are  you  using? 

6.  Do  you  use  S 1000D  to  integrate  technical  and  training  data? 

a.  [If  “yes  ”]  How  was  that  done? 

b.  [If  “no’’]  Given  what  you  know  about  benefits  of  S1000D  for  technical 
data,  could  those  same  benefits  be  realized  for  technical  training? 

7.  What  challenges  have  you  encountered  in  using  S 1000D? 

a.  How  have  you  overcome  those  challenges? 

b.  Do  you  have  any  specific  objections  to  using  S1000D  based  on  the 
challenges  you  have  encountered? 

8.  Would  you  favor  a  DoD  requirement  to  use  S 1000D? 

a.  [If  “yes  ”]  Why  would  you  favor  S1000D  becoming  a  DoD  requirement? 

i.  What  does  DoD  need  to  do  to  help  implement  a  requirement  to  use 
S1000D? 

ii.  What  would  your  program  or  organization  need  to  do  to  comply 
with  a  S 1 000D  requirement? 

iii.  Do  you  think  a  S1000D  requirement  should  apply  to  all  DoD 
technical  information  procurement  or  is  there  a  class  or  size  of 
procurement  to  which  the  requirement  should  not  apply? 

iv.  Do  you  think  DoD  and  industry  should  collaborate  to  develop  an 
enterprise-wide  approach  to  technical  information  before  making 
S1000D  a  requirement? 
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1.  If  so,  what  would  be  some  key  components  of  that 
approach? 

v.  Do  you  believe  S1000D  should  be  adopted  for  uses  beyond  the 
structuring  of  traditional  technical  publications? 

1 .  If  so,  what  kinds  of  uses? 

b.  [If  “no”\  Why  are  you  not  in  favor  of  S1000D  becoming  a  DoD 
requirement? 

i.  Would  you  prefer  the  status  quo  or  for  DoD  to  make  some  other 
standard  a  requirement? 

1 .  If  some  other  standard,  which  one? 

ii.  What  would  be  needed  to  enable  you  to  support  S 1000D  becoming 
a  DoD  requirement? 

If  no,  you  are  not  using  S1000D: 

1 .  Did  you  or  your  organization  consider  using  it  on  any  programs? 

a.  If  so,  why  did  you  or  your  organization  decide  against  it? 

b.  Did  you  choose  an  alternative  specification? 

2.  Do  you  plan  to  use  S 1000D  in  the  future?  Why  or  why  not? 

a.  If  planning  to  use  S1000D  in  the  future,  do  you  have  an  estimate  of  cost 
and  time  to  convert  or  “re -tool”  to  employ  S1000D? 

3.  Is  your  technical  data  strategy  based  on  DoD  policy  or  internal  corporate 
procedures,  processes,  tools,  and  standards? 

4.  Would  you  favor  the  government  establishing  a  requirement  to  use  S 1000D? 

a.  [If  “yes  ”]  Why  do  you  favor  S1000D  becoming  a  DoD  standard? 

b.  [If  “no”]  What  are  your  objections  to  having  S1000D  become  a  DoD 
requirement? 

i.  What  would  need  to  change  to  enable  you  to  support  S1000D 
becoming  a  DoD  requirement? 
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ii.  Do  you  believe  the  Government  should  determine  a  structure  for 
developing  a  comprehensive  enterprise-wide  approach  to  product 
data  before  making  S1000D  a  requirement? 

1 .  If  yes,  what  would  be  the  key  components  of  that  approach 
that  would  enable  you  to  support  S1000D  becoming  a  DoD 
requirement  for  technical  publications? 

[Closing  Question  for  all  participants ] 

Is  there  anything  else  you  would  like  to  add  regarding  this  study  to  determine  if  S1000D 
should  become  a  DoD  requirement  for  technical  publications? 

[Conclusion  of  the  interview ] 

That  concludes  our  interview.  Thank  you  for  your  participation.  We  have  a  short  set  of 
follow-up  questions  we  would  like  to  send  you.  These  will  help  us  perfonn  some  quantitative 
analysis  of  aspects  of  this  study.  It  will  only  take  about  5  minutes  to  respond  to  that  set  of 
questions.  May  we  send  you  the  follow-up  questions? 

Thank  you  again  for  your  time  and  the  information  you  provided.  If  you  want  additional 
information  from  us  about  this  project  at  any  time,  feel  free  to  contact  [ researcher  name,  phone, 
e-mail ]. 
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APPENDIX  B  -  QUESTIONNAIRE  SURVEY 


S1000D  Survey 

Background 

S1000D  is  an  international  standard  for  technical  publications.  It  was  developed  in 
Europe  by  the  aerospace  industry  and  has  grown  and  spread  to  encompass  all  types  of 
transportation  systems  and  many  military  systems.  DoD  has  “adopted”  S1000D  by  stating  that  it 
is  approved  for  use  in  DoD  acquisition  programs  and  systems,  but  is  not  required.  S1000D  is 
based  on  XML  and  establishes  a  standard  for  metadata  to  index  all  data  on  system  components 
and  supports  technical  documentation  and  Interactive  Electronic  Technical  Manuals  (IETM). 
DoD/OUSD/AT&L  is  interested  in  evaluating  the  question  of  whether  S1000D  should  be 
required.  The  present  study  was  designed  to  gather  information  and  opinions  of  experienced 
users  relevant  to  that  decision. 

Directions 

Please  do  NOT  put  your  name  on  this  survey.  Responses  to  this  survey  will  remain 
anonymous. 

My  level  of  knowledge  of  S1000D  is  (Select  one): 

12  3 

I - 1 - 1 

Weak  Marginal  Strong 

If  you  selected  #1  above,  thank  you  for  your  time,  we  will  not  be  able  to  use  your  data. 
Please  submit  your  Questionnaire  now. 

Each  Question  below  is  constructed  as  a  5-point  scale,  anchored  with  “Strongly  Agree” 
and  “Strongly  Disagree” 


1 

2 

3 

4 

5 

I - 

- 1 - 

- 1 - 

- 1 - 

- 1 

Strongly 

Agree 

Agree 

Disagree 

Strongly 

Disagree 

Don’t  Know/ 
NoOpinion 

Some  people  favor  a  DoD  requirement  for  S1000D  in  all  systems;  some  think  it  should 
be  required  only  for  certain  categories  of  acquisition;  some  only  for  new  systems;  etc.  This  first 
set  of  six  questions  provides  you  with  the  opportunity  to  convey  your  opinion  on  these  issues. 

DoD  should  require  S1000D  for: 

•  ALL  DoD  acquisitions. 

•  All  NEW  DoD  acquisitions  (but  not  legacy  systems). 

•  All  large  (ACAT  I/II)  acquisitions  (but  not  small  ones  (ACAT  III/IV) 
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In  my  opinion,  DoD  should: 

•  Allow  Program  Managers  to  decide  whether  of  require  S 1000D 

•  Allow  each  Service  to  establish  policy  on  whether  to  require  S 1000D 

•  Promote  and  encourage  the  use  of  S 1000D,  but  NOT  require  it 

•  Require  S1000D  but  allow  an  “Opt  Out”  when  preliminary  analysis  of  the  “Business 
Case”  does  not  support  the  use  of  S1000D  for  specific  programs  or  systems 

Several  potential  benefits  have  been  suggested  as  flowing  from  the  use  of  S1000D. 
From  your  experience,  which  of  the  following  benefits  do  you  believe  are  likely  to  be 
realized? 

•  Efficiencies  from  “Reuse”  of  data 

•  Links  between  logistics/technical  data  and  training  (SCORM) 

Other:  Please  specify _ 

Some  people  believe  that  DoD/OSD  should  participate  more  vigorously  in  activities 
related  to  the  management  of  technical  data,  whether  or  not  the  use  of  S1000D  is  made  a 
requirement.  Please  indicate  your  agreement  with  the  following  potential  DoD/OSD 
activities 

•  Promote  an  enterprise-wide  solution  to  managing  technical  data 

•  Advertise  and  promote  the  user  of  S 1 000D 

•  Participate  actively  in  S1000D  international  policy  boards 

•  Provide  funding  for  training  and  transition  to  S 1000D  usage 

•  Promote  the  consistency  and  compatibility  of  S1000D  Business  Rules  (BREX)  across 
Services 

Several  potential  drawbacks  or  downsides  to  the  use  of  S1000D  have  been 
mentioned.  Please  rate  your  agreement  with  the  following  items: 

•  Software  tools  for  implementing  S1000D  can  create  incompatibilities 

•  S1000D  is  changing  rapidly  and  has  some  problems;  let’s  wait  until  it  becomes  more 
stable 

•  The  DoD  should  avoid  using  a  Standard  that  is  controlled  by  an  International  body 

•  DoD  has  not  sufficiently  investigated  the  adoption  of  the  entire  “S-series”  of 
Standards 

Please  provide  any  other  comments  or  opinions  regarding  whether  S1000D  should 
become  a  DoD  requirement. 

My  professional  experience  is  associated  primarily  with: 

_ U.S.  Army  _ U.S.  Navy /Marine  Corps  _ USAF  _ USCG 

_ Other  (Please  identify) 


Please  describe  the  strength  of  your  background  and  experience  in  these  areas: 
Note:  ACAT  =  Acquisition  Category 
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•  DoD  ACAT  I/II  Acquisition  Programs 

•  DoD  ACAT  III/IV  Acquisition  Programs 

•  Large  company  experience 

•  Small  (<500  employee)  company  experience 

•  NON-DoD  Acquisitions  and  Systems 


Thank  you  for  participating  in  this  survey  on  S1000D 
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APPENDIX  C  -  ADDITIONAL  EXCERPTS  FROM  THE  STRUCTURED 

INTERVIEWS 


Excerpts  from  the  structured  interviews  are  shown  in  italics.  Minor  editing  was  done  to 
improve  readability. 

A.  BENEFITS  EXPERIENCED  FROM  USING  S1000D 
1.  Reuse 

...by  creating  data  modules,  we  can  build  the  various  levels  of  procedures  [for  naval 
technical  procedures]  from  the  same  source  data.  So  there’s  a  lot  of  reuse  in  that 
respect.  ...  And  that  reuse,  I  think,  is  advantageous  for  any  number  of  reasons,  not  the 
least  of  which  is  efficiency,  but  also  consistency  in  the  data,  because  then  you  get  the 
same  information  written  the  same  way  time  after  time,  and  it’s  understandable,  then, 
at  the  user  level  because  they  see  it  the  same  way  every  time.  The  other  way  that  we’re 
getting  reuse  would  also  be  [to]  provide  the  fleet  training,  so  ...you  can  use  that  same 
data  again  for  training.  Also,  we  do  foreign  military  sales,  and  so  then  they  have  their 
own  version. ...  all  of  these  can  be  pointing  to  the  same  data  modules  and  can  be 
reused  to  be  consistent.  That  also  makes  a  huge  difference  ...  when  you’re  looking  for 
cost  impacts  on  life  cycle  changes. 

[benefit  of  using  S1000D]  ...it  would  be  the  same  benefits  of  using  XML  in  general, 
which  would  be  reuse  and  repurposing  of  the  data  so  that  you  end  up  saving  some 
maintenance  time,  some  development  time. 

...standard  way  to  house  the  information  that  we’re  looking  at...  can  be  placed  into  a 
database  that  other  people  can  access  and  shared  among  other  people  in  the 
community  that  can  also  use  that  information...  Reuse  would  be  a  large  benefit, 
because  anyone  that’s  familiar  with  technical  data  realizes  that  there  are  procedures, 
and  there  are  items  that  are  repeated,  depending  on  what  the  user’s  going  to  be 
doing...  maintenance  becomes  easier  because  of  that  reuse  and  because  it’s  not  simply 
copying  something  to  show  it  in  a  different  procedure.  It’s  actually  linking  or  using  the 
same  information  so  that  changes  are  made  in  one  place  and  updated  in  multiple 
areas. 

We  have  found  reuse  is  readily  available  within  a  particular  project  or  type  of 
equipment,  but  we  have  not  found  as  much  across  the  board,  [because  of  the  diversity 
in  the  kinds  of  systems  being  documented]  So  within  a  commodity,  there’s  a  lot  of 
reuse,  but  when  you  move  outside  of  a  commodity,  there’s  not  as  much  reuse. 

In  Europe,  the  implementation  ofSIOOOD  was  begun  as  a  means  of  ensuring  that 
multiple  agencies,  multiple  countries  could  work  together  efficiently.  If  their 
machining  programs  were  to  take  place  in  Germany,  France,  Italy,  and  Spain,  then  the 
implementation  of  SI  000D  ensured  that  when  they  were  complete,  the  technical  data 
had  the  same  look  and  feel  without  regard  to  where  it  was  written. 
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2.  Cost  Savings 

Particular  case  of  a  radio  procured  by  the  United  Kingdom.  It’s  used  on  their  airships, 
on  aircraft,  on  their  surface  vehicles,  on  their  sea-surface  vehicles.  It’s  used  everywhere 
in  the  military.  ...  They  bought  the  S1000D  data  for  this  radio  in  terms  of  its  operation 
instructions  one  time,  and  now  they  can  simply  reuse  those  operating  instructions  in 
all  of  those  different  vehicles. 

...You  may  not  save  any  money  initially,  but  over  the  lifecycle  [you  will] 

I  can  see  where  the  standardization  would  be  beneficial  for  all  ofDoD  because,  as  we 
go  forward,  we  know  our  budgets  are  going  to  get  tighter  and  tighter,  and  if  we’re  out 
there  using  different  software  and  different  procedures  to  do  the  same  job,  it’s  only 
going  to  cost  DoD  more  money  overall. 

...as  more  programs  decide  to  go  down  this  road  and  use  this  information,  the  reuse 
capability  will  pay  off  in  the  long  run  because  it’s  going  to  cut  down  on  program 
funding  required  to  develop  the  IETM. 

We  have  seen  a  benefit  in  the  training  area  in  that  a  lot  of  the  training  information  is 
the  same  information  that’s  used  in  the  IETMs 

...we’re  being  able  to  leverage  our  support  contractors,  who  are  also  supporting  other 
SlOOOD-based  efforts, ...  we  are  then  reaping  the  benefit  of  both  their  experience  and 
their  expertise  and  their  cost  savings  because  they  are  able  to  leverage  their  overhead 
costs  and  pass  that  savings  to  us,  their  customer. 

[cost  data]...  it’s  too  early,  but  as  the  project  lead  I'm  encouraged,  and  I  think  my 
customers  are  pleasantly  surprised  relative  to  [a]  our  initial  estimates;  (b)  our  actuals; 
and  [c]  what  we've  accomplished  for  the  amount  that  we’ve  invested  so  far. 

The  government  did  not  pay  for  the  conversion.  We  paid  for  it  out  of  our  funding,  and 
did  so  because  we  could,  and  in  fact  did  achieve  a  savings  in  technical  data 
maintenance  cost,  and  in  the  amount  of  time  it  took  to  perform  maintenance,  and  in 
the  time  that  it  took  us  to  turn  around  changes  in  technical  publishing.  We  could 
produce  changes  in  technical  data  much  quicker  with  the  S1000D  format. 

The  government  is  paying  a  fortune  for  information  and  having  it  maintained  multiple 
times,  and  these  are  costs  that  could  be  avoided. 

We’re  seeing  a  reduction  in  cost  as  well  as  an  emphasis  now  more  on  the  technical 
content  of  the  writing  instead  of  the  style  and  format. 

...if you’re  considering  just  the  beginning  of  the  life  cycle,  the  acquisition  phase,  you’re 
going  to  see  benefits  in  terms  of  shortened  authoring  times,  the  immediate  update  of 
data  throughout  all  applicable  publications  that  that  data  module  touches.  It’s  a  little 
too  early  for  the  most  part  to  say  that  we  see  benefits  in  sustainment  and  operations 
and  support  and  all  of  that,  but  I  can  definitely  see  that  that  is  going  to  be  a  benefit. 

I  would  say  that,  in  terms  of  what  people  expected  to  get  from  contracting  for  SI  000D, 
tools  and  data,  it  surpassed  their  expectations  for  their  project. 

3.  XML  and  Other  Benefits 

...one  of  the  advantages  that  I  see  in  SI  000D  is  that  it  does  offer  a  level  of  flexibility,  so 
that  when  there  are  requirements  to  tailor  based  on  customer  requirements  or 
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technical  requirements,  it  allows  for  that  flexibility  while  still  providing  the  structure 
and  the  road  map  that  you  need  for  the  commonality  and  consistency. 

To  me,  the  best  thing  about  S1000D,  for  joint  services  and  internationally,  is  that  we 
are  all  using  the  same  spec.  If  we’re  all  using  the  same  spec,  we  can  all  develop  tools 
that  support  that  same  spec,  and  we  can  all  speak  the  same  language  to  each  other, 
amongst  the  services.  And  for  those  who  have  to  develop  policy,  we  can  reuse  policy 
letters,  we  can  reuse  presentations,  training,  tools,  and  research.  Just  about  anything 
that  you  can  think  of  related  to  policy  now  becomes  something  that  we  can  do  joint 
service  or  even  internationally. ...  With  S1000D,  we  just  look  at  one  spec  and  one  way 
to  make  that  work  with  engineering  models,  and  then  the  services  make  that  work  in 
their  business  practices. 

SI  OOOD  ...  offers  us  an  opportunity  for  a  flexible  set  of  technical  data  products  for  our 
current  customers. 

So  S1000D  not  only  permits  content  reuse  for  training  deliverables,  it  borrows  content 
itself  from  engineering  databases  that  are  further  back  in  the  product  lifecycle  process. 
So  it's  an  integral  part  of  a  wider  set  of  specifications  that,  when  you  bring  them  all 
together,  are  focused  on  the  threefold  support  of  this  system  from  its  inception  and 
design  and  manufacture  through  to  its  in-service  and  ultimately  demilitarization 
phases.  ...the  use  of  these  complementary  standards  is  now  becoming  what’s 
considered  best  practice  in  the  U.S. 

S1000D  has  a  way  to  place  each  and  every  piece  of  technical  data  under  configuration 
control.  And  that  configuration  control  ensures  that  you  are  always  getting  the  right 
piece  of  technical  information  to  make  the  repair  to  the  components  that  you  have.  So 
that,  I  think,  is  a  particular  value  over  the  lifecycle  of  equipment,  the  ability  to 
configure,  to  have  configuration  control  over  the  technical  components  of  the 
technical  publications  and  the  ability  then  to  make  sure  you  get  a  right  piece  to  make 
the  repairs  you  need  to  make.  I  think  that  will  reduce  overall  the  cost  of  maintaining 
that  equipment  over  time. 

...now  everybody  will  be  able  to  find  data  arranged  in  the  same  style  and  format;  and 
that,  I  think,  will  facilitate  working  with  our  NATO  and  other  partners. 

The  thing  that’s  nice  about  S1000D  is  that  it’s  XML.  ...  So  if  you  have  a  standard  Web 
person  that  is  used  to  working  with  markup  languages  like  XML,  it’s  very  easy  to  train 
them  a  step  further. ...  For  the  majority  of  your  production  workforce,  they  just  need  to 
be  trained  on  the  tool  that’s  going  to  be  used.  Then  you  have  a  small  group  that  know 
the  S1000  schema  in  and  out  and  can  troubleshoot  or  plan  for  those  type  of  things. 

The  other  major  advantage  I  see  is  for  customers  on  the  acquisition  side  because  of  the 
fact  that  SI  OOOD  is  XML.  It’s  internationally  accepted  technical  data  standard  for  tech 
docs.  ...because  of  the  tools  that  are  available  and  the  expertise,  I  think  it  mitigates  risk 
for  customers  because  they  have  people  that  know  how  to  use  S1000D  and  know  how 
to  use  the  tools,  and  they  can  easily  migrate  the  data. 

...the  other  major  advantage  is  the  customization  and  tailorization  that’s  build  into 
the  specification. 
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...the  data-centric  nature  of  the  spec  makes  it  easier  to  find  ways  to  take  legacy  data 
and  convert  it  over,  because  you  can  model  almost  anything  with  the  spec  once  you’re 
experienced  with  it 

...the  primary  benefit  that  1  see  is  the  general  capability  of  modularization  of  data  and 
the  data  module  codes  that  allow  you  to  take  various  pieces  of  data  by  information 
type  and  correlate  them  together. 

We  are  using  the  SlOOODfor  all  types  of  data  that  you  would  normally  find  in  a 
maintenance  level  IETMfor  on-board  use,  so  we  have  typically  units  or  enclosures  that 
have  various  types  of  electronic  systems,  hardware  in  them,  like  servers  and  switches, 
and  all  kinds  of  things  like  that,  various  electronics  components;  and  we're  obviously 
documenting  things  like  operating  procedures  and  remove-and-replace  procedures 
and  functional  descriptions,  cabling  diagrams  and  wireless  tables,  troubleshooting 
procedures,  which  usually  in  our  case  right  now  take  the  form  of  flow  charts. ...physical 
description  of  parts  data. ..documenting  a  lot  of  system-level  data.  We  have  system- 
level  functional  descriptions,  but  we  are  also  documenting  our  operational  displays 
and  things,  software  itself,  graphical  user  interfaces  and  controls,  indicators  and  so 
forth,  which  isn’t  something  that  typically  SI  OOOD  is  used  for  because  it’s  typically 
used  for  hardware  maintenance-type  manuals. 

A  lot  more  process  maturity,  it’s  a  scheme  that  they’re  going  to  bring  greater  control 
over  quality  of  the  document  and  structure  and  reusability  of  the  document.  And,  if  we 
do  any  collaboration  with  allies,  they’re  using  S1000D  in  Europe. 

[S1000D]  is  allowing  us  to  get  consistent  data  and  data  element  names  and  everything 
that  feed  into  our  maintenance  capture  system. 

B.  CHALLENGES,  POLICY  AND  GETTING  STARTED 

1  think  when  we  first  started  developing  policy  for  S1000D,  we  really  thought  there 
would  be  a  better  organized  and  funded  approach  to  supporting  the  U.S.  side  of  the 
spec,  because  it  seemed  clear  that  it’s  a  good  idea  to  add  S1000D  into  the  mix  for  all 
the  services  because  it’s  someplace  that  we  can  go  to.  ...  the  expectation  was  that  OSD 
would  provide  some  intelligent  support  for  S1000D  in  a  joint  service  capacity... 
Basically  over  the  years  it’s  just  come  to  be  realized  that  OSD  is  not  going  to  support 
this,  fund  this,  look  at  this,  or  do  anything  with  it.  And  so  the  services  have  protected 
their  needs  by  just  being  friendly  and  getting  together  and  coming  up  with  answers  to 
things. ...  So  1  guess  what’s  disappointing  to  me  is  that  OSD  has  not  stepped  up  and 
said,  you  know  what,  this  is  clearly  something  that  the  U.S.  has  to  protect  their  interest 
in,  because  our  services  and  our  programs  are  using  this  spec. ...  that  doesn’t  make 
sense  that  all  these  U.S.  programs,  these  military  programs  are  depending  on  the  spec 
to  support  them,  and  yet  OSD  is  not  funding  it  and  has  no  way  to  do  so,  not  even 
thinking  about  it. 

There  are  issues  with  life  cycle  maintenance,  when  you  consider  the  infrastructure  of 
the  Navy  is  not  really  geared  to  tracking  and  maintaining  the  DMs,  so  ...  we  sort  of  had 
to  work  through  that. ...  It’s  difficult  when  in  some  ways  you’re  doing  something  before 
the  infrastructure  is  caught  up. 

If  you  don’t  have  the  service  business  rules  in  place,  then  you  would  have  to  interpret 
all  of  the  existing  policy  for  that  service  and  think  about  it  yourself  in  terms  of  what 
does  that  mean  I  need  to  do  in  S1000D.  That’s  a  lot  of  work. 
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...And  then  the  challenge  with  the  S1000D  piece  of  this  [neutral  file  format  for  CAD 
data]  was  that  they  were  attempting  to  create  kind  of  a  virtual  environment  for  the 
sustainment  enterprise,  [but  no  discussion]  where  this  S1000D  formatted  document 
would  fit  within  the  framework  of  a  product  life  cycle  management  environment.  The 
answer  is  that  the  document  and/or  process  is  subordinate  to  the  product  structure. ... 
they  didn’t  understand  productization  and  they  didn’t  understand  product 
sustainment.  What  they  really  understood  is  the  creation  of  tech  documents  and 
publications  and  viewers. 

We’re  starting  to  have  some  concerns  with  the  proliferation  of  contractor  unique  tools 
and  applications  for  our  acquisitions.  So  I  would  like  to  see  a  little  bit  more 
standardization  in  that  area.  ...  1  would  like  to  see  more  standardization  of 
applications  in  the  acquisitions  environment  across  programs. 

1  would  say  that  trying  to  standardize  the  implementation  of  the  program  across  the 
various  acquisition  projects  and  sustainment  has  been  a  challenge  because  people 
started  using  it  and  buying  the  data  before  we  had  any  business  rules  established. 

1  think  because  it’s  not  required,  most  organizations  have  their  own  system  for  storing 
technical  data. 

Sometimes  people  may  have  an  expectation  that  the  production  ofSIOOOD 
information  will  be  inexpensive.  There  is  substantial  overhead.  Every  data  module  has 
a  block  of  information  associated  with  it.  This  is  all  the  metadata,  the  information  that 
describes  pretty  much  what’s  going  to  be  contained  in  the  data  module,  and  provides 
all  of  the  configuration  control  information;  and  that’s  a  little  expensive  to  maintain. 
And  1  think  sometimes  that  they  believe  that  legacy  information  prepared  to  another 
specification  can  be  easily  transported  into  S1000D,  and  that  too  is  not  the  case. 

One  area  we  have  not  seen  and  really  thought  we  would,  would  be  the  reduction  in  the 
initial  authoring  cost. 

[Expectations]  may  not  be  met  as  quickly  as  some  might  hope,  like  as  far  as  return  on 
investment ...  because  there  is  a  lot  of  effort  and  a  lot  of  costs  upfront,  and  it  will  take 
a  while  to  start  seeing  return  on  investment  from  that.  First  of  all,  training  is 
important.  It’s  an  extremely  complex  vocabulary.  So  training  and  learning  curve  is 
certainly  part  of  it.  ...The  good  news  is  there  are  several  companies  out  there  ...  that 
are  building  these  tool  sets  around  S1000D,  to  try  to  reduce  the  complexity.  ...  The  bad 
news  is  they  are  all  extremely  expensive. 

The  benefits  of  using  S1000D  are  probably  going  to  show  up  a  little  bit  later  in  the  life 
cycle.  ...  in  the  beginning  it's  the  same  amount  of  work,  but  your  savings  come  about 
later  in  the  process. 

...because  some  of  my  end  products  are  fairly  complex  and  fairly  large. ..our  start-up 
cost  is  pretty  significant.  ...And  there  are  going  to  be  a  lot  of  process  changes  that  are 
going  to  have  to  happen  compared  to  what  we  do  now.  ...I  think  these  costs  can  be 
recouped  over  the  life  cycle. 

I  think  the  only  problem  is  that,  for  people  who  work  on  primarily  on  very  small 
projects,  it’s  hard  to  get  started.  You  have  to  take  a  step  back  and  figure  out  a  phased 
approach  to  get  past  the  learning  curve  and  establish  written  business  rules  and 
coordinating  with  all  the  organizations.  For  example,  I'm  trying  to  work  with  the  Joint 
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Services  Department  and  NAVSEA  on  one  of  my  projects,  where  I'm  trying  to 
coordinate  across  those,  make  sure  that  my  business  rules  are  compatible  with  theirs. 
That  takes  some  time. 

...the  paradigm  shift  of  contractors  as  well  as  government  employees  has  been  a  major 
problem  at  the  beginning.  But  once  they  have  seen  how  we  compartmentalize  data 
and  everything,  they  actually  like  it  better  than  the  old  way  we  did  business. 

When  we  first  started,  it  was  difficult  to  find  people  to  do  SI  OOOD.  But  over  the  last 
four  years  that  we  have  been  doing  it,  it’s  relatively  easy.  We  have  a  whole  slew  of 
contractors  that  now  can  produce  this  data.  So  we  have  done  some  home-growing 
internally  as  far  as  the  contractors  around  us,  and  mentored  them.  In  fact,  they  have 
gone  as  far  as  built  their  own  users  group  outside  the  fence,  and  they  actually  interact 
with  each  other  and  help  each  other  with  S1000D. 

Subsequent  iterations  of  the  standard  have  become  more  and  more  complex  and  more 
nuanced,  to  the  degree  now  where  the  doc  for  the  specification  itself  was  in  excess  of 
2,700  pages,  and  that’s  unwieldy  by  any  measure.  And  then  it  begs  the  question  of  how 
you  define  the  product  support  enterprise,  and  then  what  other  ancillary  systems  and 
what  interactions  are  necessary  to  support  other  systems  and  facilitate  the 
maintenance  of  those  weapons  systems.  So  it’s  a  very  difficult  problem,  and  it’s  not  one 
that  many  people  appreciate  or  fully  understand.  ...  it’s  the  nuance  and  it’s  the 
specificities  that  sit  beneath  this  that  make  it  difficult  to  implement. ...  Today  it’s  being 
done  with  the  Tech  Doc  and  publications  world,  and  it’s  being  done  on  a  service 
vertical,  and  more  specifically  than  that  on  a  platform  vertical.  And  it’s  not  being  done 
within  the  framework  of  the  context  of  the  actual  enterprise  that’s  responsible  for 
supporting  that  asset.  Really,  the  documentation  needs  to  be  structured  within  the 
framework  of  the  overall  enterprise  and  not  within  the  framework  of  the  way  a 
specific  asset  is  going  to  be  used  in  a  specific  environment,  [issues  with  who  stores  the 
data  in  what  repository  when  the  information  is  being  used  in  multiple  products]  ...the 
content  associated  with  those  documents  is  really  compartmentalized  to  whatever  is  in 
those  repositories.  Meaning  that,  unless  they’re  tracked  from  a  revision  change 
management  perspective  with  the  asset  class  that  those  support,  you  lose  your ... 
authoritative  relevance.  ...  It’s  a  higher  order  issue  than  just  S1000D,  but  it’s  very  much 
manifested  and  comes  to  the  surface  when  you  talk  about  creating  this  environment. 

[customization  and  tailorable]  ...some  people  would  see  that  as  a  negative  and 
potential  to  share  data,  but  I  think  as  long  as  your  business  rules  are  in  place  across 
the  groups  that  you  work  with  and  you’re  following  those  and  as  well  as  within  your 
communities  of  practice,  that  could  be  managed. 

There  are  many  challenges.  ...it’s  necessary  to  understand  how  products  are  delivered 
and  then  how  they’re  sustained  in  order  to  appreciate  that  this  is  probably  not  possible 
in  this  environment.  And  the  reason  is  that  the  products  that  are  in  inventory,  if  you 
look  at  the  -  like  an  aircraft,  are  built  of  subsystems  and  components,  and  the  product 
structure  is  built  from  catalog  items  which  then  moves  into  subassemblies  which  are 
built  into  product  configurations  and  then  are  fielded  and  maintained.  And  you  have 
as  designed,  as  built  and  as  maintained,  building  material  and  other  artifacts 
associated  with  supporting  those  items  once  they're  in  inventory.  The  common  item 
data  that  these  folks  in  the  tech  pub  environment  want  to  use  as  content  is  not 
changed  in  synchronization  with  the  assets  that  are  fielded.  Consequently,  you  don 't 
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have  an  authoritative  link  between  the  bits  and  pieces  that  fit  within  the  common 
objects  and  database  and  the  items  that  are  actually  in  use.  There  is  no  direct  linkage 
or  connection  there.  One  of  the  things  they  tried  to  do  in  later  issues  of  the  standard  is 
to  build  a  mini  product  life  cycle  management  or  product  data  management 
environment  within  the  common  object  database  such  that  repair  parts  could  be 
ordered.  Likewise,  the  training  -  linkages  to  training  videos  or  other  training  aids 
could  potentially  be  enabled  or  facilitated.  They're  really  attempting  to  do  a  lot  with  a 
document  management  environment.  That's  essentially  what  it  is.  And  without  the 
work  -  work  pools  and  the  work  flow  and  the  work  flow  management,  without  an 
understanding  of  the  content  with  respect  to  the  actual  end  items  that  are  being 
maintained,  it's  extremely  difficult  to  do  that.  You  know,  there  is  no  linkage  to  the 
catalog  of  end  items  and  lists  and  the  things  that  are  being  done  with  content  space. 

So  it  really  becomes  a  sub-optimization  routine  in  the  sense  that  you  may  be 
optimizing  the  generation  of  documentation,  but  you're  doing  that  to  the 
disadvantage  of  other  enterprises  within  the  -  within  the  organization.  And  in  order 
to  maintain  semantic  relevance  in  this  environment ...  another  point  that  I  think  is 
very  important  -  changing  the  tire  in  the  desert  is  different  than  changing  the  tire  in  a 
jungle.  Unless  you  understand  the  distinctions  associated  with  [these  environments]  - 
if  you  try  to  generate  a  document  which  can  apply  to  this  level  of  semantic  relevance  to 
specific  environments  on  the  fly,  without  human  intervention,  you're  probably  going  to 
end  up  with  sort  of  a  Chinese  bicycle  manual.  And  the  problem  is  that  the  folks  who 
are  typically  associated  and  involved  with  this  activity  are,  for  the  most  part,  content 
developers  in  the  publications  environment.  They  really  are  not  maintainers  or 
sustainers  or  the  people  who  are  working  at  the  edge  and  are  responsible  for 
supporting  those  weapons  systems. 

The  biggest  challenge  with  S1000D  just  getting  started  is  that  it  is  front-loaded  as  far 
as  the  work  in  doing  a  project.  So,  for  example,  you  have  to  be  able  to  answer  all  of 
those  questions  about  how  you’re  going  to  do  a  project.  You  have  to  be  able  to  answer 
all  the  questions  about  what  kind  of  data  module  coding  you  're  going  to  use.  You  're 
going  to  have  to  look  at  the  project  and  decide  how  you  're  going  to  divide  up  your 
data.  You  have  to  do  a  sort  of  an  analysis  of  the  reuse.  So  we  did  like  a  matrix  of  the 
different  types  of  manual  output  and  then  where  the  different  pieces  of  data  were 
reused,  so  that  we  could  get  a  map.  That's  a  lot  of  work  upfront  when  you  're  really 
not  sure  how  it  all  works  anyway,  you  know.  That's  the  hard  part,  getting  started.  It's 
really  front-loaded  with  a  lot  of  analysis.  ...  the  real  essential  up-front  analysis  and 
planning  that  has  to  be  done.  Otherwise,  the  risk  of  rework  and  re-rework  and  having 
one  step  forward,  2  steps  back,  there  is  risk  there.  But  what  we’re  finding  is  the  more 
familiar  we  are  with  our  S1000D  requirements  and  where  we  have  limitations  and 
where  we  have  flexibility  really  lends  itself,  then  to  expediting  that  planning  project. 

C.  WHETHER  DOD  SHOULD  REQUIRE  THE  USE  OF  S1000D 

If  you’re  starting  from  a  brand  new  platform,  new  boat,  new  plane,  new  cutter,  I  would 
think  it  would  be  the  default  [specification], ...  that  would  be  my  personal 
recommendation. 

The  services  are  moving  ahead.  They  are,  for  the  most  part,  proponents  of  the 
specification.  The  actual  use  and  application  of  it  needs  to  be  a  little  bit  more  defined 
to  make  it  more  cost  effective  ...  and  to  be  able  to  really  exchange  data  better.  But  if 
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you  don’t  make  it  a  requirement,  then  what  are  your  chances  of  getting  the  funding  to 
actually  be  able  to  try  to  execute  some  of  these  enhancements  to  the  specification? 

I  think  it  would  make  sense  for ...  new  content.  Anything  above  ACAT  Level  II  should  be 
using  S1000D. 

Personally,  absolutely.  I  think  its  way  overdue.  I  don’t  believe  in  all  or  nothing.  And 
what  I  mean  by  that  is  that,  for  new  acquisitions,  you  could  make  a  really  good  case  of 
why  it’s  a  good  idea.  Specifically,  especially  in  aerospace  and  with  planes,  it’s  already 
mandated.  The  private  sector  has  already  mandated  it  for  commercial  airlines. 

It  would  make  sense  to  use  a  singular  data  structure  that  we  would  simply  be  able  to 
transfer  the  data  when  we’re  doing  a  manual  that  NAVAIR  uses  and  Air  Force  uses. ... 
There  are  not  only  the  Navy’s  NAVAIR/NAVSEA  differences,  at  the  DOD  level,  there’s 
Army,  Navy,  Air  Force.  Any  commonality  is,  in  my  mind,  a  good  thing. 

Sometimes  when  people  talk  about  SI  OOOD,  I  feel  like  they’re  making  it  into  a  bigger 
shift  that  it  really  is.  We  already  have  a  requirement  for  XML  to  be  used  for  technical 
manuals,  and  the  spirit  of  that  is  so  that  we  can  share  data.  The  problem  is  that  we 
allow  everybody  to  go  by,  or  create,  the  structure  rules  that  they  want,  as  long  as  it’s  in 
XML,  which  means  that  we  don’t  have  consistency  and  we  can’t  share  the  data. 

SI  OOOD  is  a  specification  that  brings  a  consistent  structure  ...  and  what  you’re  saying 
is  we’re  just  going  to  apply  consistent  rules  to  the  way  we  purchase  the  data. 

I  think  the  objection  would  be  about  all  the  caveats  that  they  would  mandate.  If  it  were 
a  brand-new,  huge  weapons  system,  I  don’t  think  anybody  would  object  if  that’s  the 
criterion. ...  So  if  you  can  be  very  clear  about  which  ones  are  the  things  that  are 
actually  mandated  and  leave  everybody  else  alone  to  make  the  decisions  that  they 
need  to  make,  and  not  require  this  long,  complicated  list  of,  if  this  happens,  then  you 
have  to  do  it,  but  if  this  doesn't  happen,  then  look  at  this  and  then  give  us  this  cost ...  all 
this  is  too  time-consuming  and  not  something  anyone  really  needs  to  define.  This  is 
going  to  confuse  the  issue. 

Across  the  board  would  not  work.  It  just  doesn’t  make  sense  in  so  many  environments 
to  convert  that  data. 

If  there  is  no  old  stuff,  then  it  seems  really  clear  that,  if  you  don’t  have  any  existing 
data,  you’re  not  reusing  anything.  This  is  a  whole  new  development,  SI  OOOD  seems 
like  a  no-brainer. 

I  think  the  short  answer  is  yes.  Speaking  as  a  contractor,  it’s  extremely  helpful  to  have 
top-down  directional  flow  for  policy  and  guidance. ..also  beneficial  to  have  clear, 
concrete  acquisition  guidance  flowing  down. 

I  wish  the  outcome,  the  recommendation  by  LMI  to  OSD,  would  have  been  to  say  "yes," 
make  the  decision  [to  require  S1000D],  Unfortunately,  I  believe  my  interpretation  of 
the  study  is  that  they  delayed;  they  did  not  in  the  end  make  that  recommendation.  And 
I  certainly  was  part  of  the  camp  that  was  looking  for  and  very  hopeful  that  we  would 
have  gotten  a  direction  from  OSD  to  strongly  recommend  something  in  those  terms. 

I  think  the  OSD  guidance  may  be  a  strongly  suggested  use  of  the  standard  with  a 
caveat  to  allow  acquisition  managers  -  based  on  a  business  case  or  a  set  of  business 
rules,  either  one  -  to  at  some  point  opt  out  of  it,  if  that  truly  makes  sense.  I  worry  a  bit 
about  the  word  "mandate’’.  There’s  got  to  be  some  common  sense  applied.  So  I  would 
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really  applaud  an  OSD  strongly  embracing  the  standard,  but  not  a  black  and  white,  cut 
and  dried,  you-will-or-will-not  kind  of  thing. 

Not  appropriate  to  use  SI  OOOD  if  you  have  something  that  has  short  technical  life,  like 
a  telephone.  To  document  a  telephone  in  S1000D  would  be  impractical.  There  are 
other  mechanisms  for  structured  data  that  are  better  for  a  piece  of  equipment  that  has 
a  short  shelf  life  or  a  short  [operational]  life  and  doesn’t  have  a  lot  of  technical 
changes. 

I  feel  pretty  strongly  that  it  ought  to  be  [required].  I  believe  that  it’s  going  to  save  the 
government  money.  I  believe  it’s  going  to  make  it  easier  for  people  to  find  technical 
information.  I  think  it’s  the  right  thing  to  do. 

I  think  it  [a  requirement]  would  help  a  lot  because  right  now,  people  are  unsure  ... 
there  doesn’t  seem  to  be  any  policy.  If  it  was  just  a  policy  that  said  it’s  okay  to  use  it,  it 
would  even  be  better  than  no  policy  at  all. 

Most  assuredly.  I  think  in  the  end  it  will  save  them  a  fortune. 

D.  ACTIONS  DOD  SHOULD  TAKE  TO  ACHIEVE  SUCCESSFUL 
IMPLEMENTATION  OF  S1000D 

I  think  what  the  DoD  has  to  do  is  take  a  look  at  what  the  service  has  done  and  look  for 
commonality  across  the  board  and  then  really  latch  onto  their  areas  of  commonality, 
and  they  would  be  obvious  candidates  for  DoD  policy.  Where  there  are  gaps,  DoD  is  the 
glue  that  brings  things  together  in  a  coordinated  fashion. 

First  and  foremost,  DoD  would  need  to  coordinate  with  the  actual  body  that’s 
responsible  for  identifying  those  requirements  for  the  services  [Joint  Service  IETM 
Technology  Working  Group]...  and  then,  second,  any  potential  funding  to  transition  [to 
SI  OOOD]  and  to  set  this  up  would  be  another  good  thing.  Third,  they  should  make  sure 
that  they  staff  someone  from  the  IETM  technology  working  group  to  represent  these 
services  and  OSD  at  these  SI  OOOD  meetings.  We  do  not  have  an  OSD  representative 
sitting  on  that  panel! 

DoD  needs  to  ensure  vendor  products  are  SlOOOD-compliant  and  that  needs  to  be 
validated. 

The  problem  is  the  acquisition  folks  may  have  heard  of  [S1000D],  and  sometimes  they 
do  put  it  into  the  contract,  but  we  haven’t  laid  out  any  road  map  for  the  infrastructure 
to  support  it.  Then  you  have  the  Program  Managers.  Technical  Documentation  is  kind 
of  the  bottom  feeder  of  their  problems.  They’re  not  really  looking  at  the  data 
structures  of  their  technical  manuals  as  high  on  their  list  of  concerns.  They  are  leaving 
that  to  the  technical  manual  managers  to  do  what  makes  the  most  sense  or  make  a 
compelling  case.  However,  if  you  have  structures  in  place,  then  most  tech  manual 
managers  and  most  program  managers  aren’t  going  to  go  switching  your  systems 
unless  there  is  a  requirement.  So  it’s  kind  of  a  vicious  cycle.  They’ve  got  "That’s  the  way 
we’ve  always  done  it"  syndrome.  ...  the  documentation  is  kind  of  a  redheaded  stepchild 
of  new  hardware  that  they’re  buying.  And  until  that  gets  mandated  to  them  by  either  a 
Navy  spec  or  a  DOD  spec,  they’re  not  going  to  deal  with  it.  The  other  thing  is  cost.  If 
there’s  an  up-front  investment  that  a  Program  Manager  is  going  to  have  to  incur  and 
they  can’t  be  readily  convinced  of  the  value-added  in  life  cycle  support ...  then  they 
[won’t  support  it]. 
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It  would  help  if  there  was  at  least  some  type  of  support  and  structure  in  place  before 
putting  in  these  requirements,  because  otherwise  you’re  going  to  have  each  branch 
developing  their  own  structures  and  you’re  still  going  to  be  stovepiped. 

I  think  putting  out  a  specification  that  provides  policy  and  guidance  for  the 
development  and  conversion  of  technical  data  is  important.  My  biggest  caution  would 
be  that  it  is  only  one  piece  of  what  an  office  would  be  responsible  for.  Giving  us  policy 
and  direction  on  how  to  develop  the  data,  but  an  organization  that  would  stand  up  to 
help  guide  that  needs  to  have  a  much  broader  scope  of  responsibility  beyond  just 
simply  how  the  data  is  developed.  If  OSD  directed  that,  they  also  should  then  follow 
that  up  with  a  group  that  would  provide  oversight,  direction,  and  assistance  to 
programs  to  those  who  were  developing  and  fielding  products.  Support  [is  needed]  in 
a  holistic  approach  to  fielding  the  product,  not  just  a  spec  to  guide  you  on  how  to 
develop  it. 

From  an  organizational  standpoint,  you  are  going  to  have  to  see  if  all  of  those  different 
organizations  that  maintain  technical  information  have  the  capability  to  house  and 
then  make  available  S1000D  information.  ...  If  it  doesn’t,  then  you  have  a  cost  involved 
with  bringing  into  that  organization  a  system  that  does.  People  would  have  to  be 
trained,  would  have  to  be  converted  over.  You  have  a  cost  of  making  sure  that  the 
organization  can  manage  the  information,  and  making  sure  that  the  workforce  is 
trained  in  that. 

DoD  should  help  with  transition  costs.  They  are  definitely  going  to  get  those  requests 
from  the  field.  Anytime  you  make  a  change  like  this,  globally  or  system-wide,  you  are 
going  to  have  pushback,  because  people  don’t  like  change,  [or  upfront  costs],  and  you 
are  going  to  get  requests  to  help  them  get  there. 

If  it's  legacy  system,  something  that  is  going  to  be  used  for  a  long  time,  conversion  [to 
SI  OOOOD}  would  need  to  happen.  But,  it  doesn’t  make  sense  from  a  system  perspective 
to  say  that  every  piece  of  legacy  information  needs  to  be  converted.  I  think  it  has  to  be 
done  on  a  case-by-case  basis:  how  stable  is  it?;  how  long  are  we  going  to  be  using  this 
technical  information?;  is  this  on  a  system  that’s  being  retired?  If  1  see  that  I  have 
technical  information  on  a  system  that’s  going  to  be  used  five,  ten  years  out ...  then 
that’s  probably  a  good  use-case  for  conversion. 

DoD  could  provide  leadership  to  expand  the  knowledge  base  and  the  training  and  the 
learning  of  the  specification,  and  especially  the  way  it  can  be  implemented.  Teach 
people  how  to  implement  and  design  business  rules,  facilitate  collaboration,  facilitate 
information  sharing,  collaboration,  and  learning. 

[DOD  should  instruct  the  acquisition  personnel  on  S1000D  what  it’s  about,  benefits, 
limitations, you  know,  the  pluses  and  minuses,  again  so  that  they  would  be  able  to 
make  determinations  on  whether  to  include  it  as  a  requirement  in  certain 
procurements]  I  think  that’s  a  big  need,  because  I  think  there’s  a  huge  knowledge  gap 
out  there  among  acquisition  people  ...  there’s  a  lot  of  folks  clamoring  for  guidance, 
people  looking  for  some  kind  of  guidance,  or  questions  about  S1000D,  everything  from 
tools  to  processes 

There  are  a  multitude  of  things  that  have  to  be  built  here.  Number  one,  we  have  to  buy 
business  rules  and  we  also  have  to  buy  the  tool,  the  database  to  actually  use  the 
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standard.  We  currently  don’t  have  that  level  of  funding  right  now.  It  is  a  significant 
investment  upfront. 

There  needs  to  he  some  improvement  in  the  acquisition  process  that  makes  it  an 
imperative  that  contractors  do  that  level  of  sharing  during  the  development  of  a 
document.  As  of  now,  the  contractors  develop  their  documents  in  their  own  pools  that 
the  government  doesn't  provide  and  they  deliver  the  final  document.  But  with  S1000D, 
you'll  need  to  have  access  to  content  that  is  at  various  points  of  completeness  and 
maturity,  and  so  you  will  want  to  be  reusing  --you'll  want  to  reuse  what  somebody 
wrote  about  the  operating  system  that  my  software  is  running  on  or  the  hardware  that 
my  software  is  running  on.  So  I'll  need  to  be  able  to  read  it,  I'll  need  to  track  where  it  is 
in  its  life  cycle  of  maturity,  what  it's  going  to  look  at  like  by  the  time  my  document 
needs  to  go  to  publication.  So  I  need  to  be  working  in  an  environment  where  I  can 
have  access  to  that  end  work  content,  which  is  something  that  typically  the  current 
culture  contractors  don't  share  until  they're  done. 

If  they  [DoD]  were  going  to  require  it  [SI  OOOD],  money  would  help. 

When  the  DOD  initial  working  group  a  few  years  ago  went  through  all  those  decision 
points  in  the  S1000D  spec  and  allocated  them  to  the  different  levels  which  one  should 
be  defined  by  DOD  -  which  by  DOD  and  which  by  SYSCOMs  -  and  which  by  the 
individual  project  or  program,  they  allocated  some  of  the  security  decision  points.  We 
would  also  need  DOD  to  be  a  participant  for  the  parts  of  the  spec  that  they  are 
responsible  for  because  we'll  need  to  all  play  in  the  same  sand  box.  We  need  somebody 
in  charge  of  the  sand  box.  Besides  just  the  business  rules  at  the  DOD  level,  we'll  need 
some  enterprise-  level  oversight  to  keep  us  all  on  track  and  sharing  and  looking  at 
each  other's  meta  data  and  acquiring  this  the  same  way  so  that  we  can  share  -  we 
know  what  we're  going  to  be  getting  when  we  share  with  each  other. 

Find  out  what  different  schemas  are  being  used  within  the  DOD  to  capture  technical 
data,  what  percentage  are  currently  using  S1000D.  Look  at  the  capabilities.  What 
databases  are  being  used  and  how  many  of  those  are  compatible  with  S1000D.  Then 
I’d  also  look  at  the  current  workforce,  how  many  people  in  the  DOD  are  currently 
working  with  technical  data  information  and  what  percentage  S1000D.  Then  you  get 
an  idea  of  training  costs. 

[We  need]  a  policy  letter  from  OSD  authorizing  the  use  of  S1000D  for  acquisition  of  life 
cycle  support 

The  DoD  needs  to  do  marketing  ...  showing  the  benefits  ofSIOOOD  and  how  you  can 
manipulate  data,  which  you  couldn’t  do  in  the  past.  Some  kind  ofDAU  type 
environment  would  be  appropriate. 
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APPENDIX  D  -  POTENTIAL  BENEFITS  OF  S1000D 


As  Suggested  by  Survey  Respondents 

1 .  Standardization  of  presented  information 

2.  Standardization,  ease  of  reuse,  keeping  up  with  technology  advancements 

3.  Common  Commercial  off  the  Shelf  software  platfonns  (authoring,  presentation)  allows 
commonality  across  services,  common  format  familiarizes  user  with  S1000D  capabilities, 
format,  etc. 

4.  Ability  to  directly  link  to  logistics  support  data 

5.  Increased  likelihood  of  receiving  accurate  data;  reduced  cost  of  maintaining  data 

6.  Data  sharing  between  services 

7.  Standardization  of  technical  data  across  platforms  and  services 

8.  Increased  Interoperability,  more  application  standardization,  lower  authoring  costs, 
improved  timeliness  of  data  updates  through  all  applicable  tech  pubs 

9.  The  ability  to  have  both  training  and  technical  data  available  at  all  times 

10.  Consistency  across  programs  promotes  familiarity  in  preparation  and  use  of  data 

1 1 .  Lower  data  ownership  costs 

12.  These  benefits  can  be  achieved  using  XML  in  general,  not  S1000D  specifically 

13.  Improved  process  maturity  for  acquiring,  building,  and  maintaining  S1000D  data 

14.  Uniformity  of  processing;  future  (unforeseen)  uses  of  data  being  in  XML  and  being 
meaningfully  cataloged  by  virtue  of  the  data  module  code 

15.  Cost  savings  over  the  lifecycle  of  projects 

16.  Interchangeability  across  services;  built-in  compliance  through  templates,  schemas, 
DTDs 

17.  S1000D  will  allow  tying  Configuration  Management  data  and  spares  data  to  technical 
manual  data  and  SCORM  all  electronically 

18.  S1000D  in  XML  is  an  enabler.  It  will  allow  DOD  and  DON  to  move  forward  in  the  area 
of  electronic  sharing  of  data  in  XML.  The  benefits  will  gradually  build  over  time. 

19.  The  only  purpose  and  benefit  of  the  S1000D  is  to  support  the  "management"  of 
prescriptive  data  modules  within  a  close-system,  proprietary  CSDB  which  is  yet  to  be 
defined  within  any  Defense  system 

20.  No  benefits  over  existing  US  based  standards.  This  European  standard  cannot  support 
links  without  use  of  a  proprietary  tool 

2 1 .  One  standard  format  of  publications  and  links  to  other  ILS  disciplines 

22.  Facilitate  true  “interactivity”  of  technical,  maintenance,  and  repair  data 

23.  Ensure  the  user  has  access  to  various  equipment/Hull/program  configurations  and  being 
able  to  ensure  the  data  within  each  applicability  DM  is  for  that  configuration. 

24.  The  assurance  and  confidence  that  data  is  presented  the  same  from  LSA  -  to  Tech  Data  - 
to  Training 

25.  Reduce  the  numerous  man-hours  spent  on  the  training/developing/maintain  the  numerous 
MIL-SPECs/STDs  and  the  DoD/NAVSEA/NAVAIR  /USAF/Army  directives  sent  to 
notify  of  updates/obsolescence  on  just  the  presentation  and  content  of  a  manual/training 
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26.  Knowing  that  multiple  contractors  on  a  program  will  interpret  and  supply  the  data  with 
the  same  look-and-feel 

27.  Standardization  of  data  formats 

28.  Standards  become  standards  for  a  reason.  If  everyone  is  on  the  same  page 
(organizationally),  life  is  just  easier. 

29.  If  properly  implemented  (DoD  has  not!),  provides  opportunities  for  reduced  training  costs 
and  improves  interoperability 

30.  Move  production  focus  toward  content  vice  format/style  and  proprietary  software 

3 1 .  A  clear  and  uniform  standard  across  the  services 

32.  Interactive  publications  will  simplify  maintenance  activities 

33.  Common  Source  Database  benefits  (sole  source  of  truth) 

34.  Reduced  cost  and  increased  efficiency  of  integration  (interfaces)  between  systems 

35.  Consistency  in  titling  of  Data  Modules.  Joint  development  between  partner  companies 
using  a  single  CSDB.  Elimination  of  file  naming  collisions.  Reusability  of  display 
engines/  transforms/  support 

36.  Rapid  updates  to  the  field—  Days  verses  months 

37.  Lower  TOC 

38.  Get  everyone  on  the  same  path  for  future  upgrades 

39.  Decrease  in  life  cycle  cost  to  maintain  fielded  data.  Also,  updates  to  data  can  be  fielded 
much  quicker 

40.  Tech  Data  Support  for  International  sales 

41.  Standardization  between  commercial  and  military  use 

42.  Richer  data  set  allows  for  more  post  publishing  functionality 

43.  Sharing  of  data  between  suppliers,  OEM's  and  end  users 

44.  Exchange  of  data  between  OEM  and  Vendors. 

45.  XML  format  is  beneficial,  however  the  data  models  are  weak  in  many  cases  and  often 
ambiguous  (read  NOT  standard) 

46.  The  more  completely  a  program  uses  S1000D  the  more  efficiencies  are  realized 

47.  Consistency  &  configuration  control 

48.  Link  between  Material  Support  data  (ASD  S2000M)  and  Tech  Pubs  (S1000D)  to  build¬ 
up  Illustrated  Parts  Catalog 

49.  Commonality  of  data  handling  procedures 

50.  Good  tech  data  configuration  management 

5 1 .  The  business  rules  and  infrastructure  are  not  in  place  to  allow  maximum  benefit  from 
using  S1000D.  Also  the  funding  is  not  available  to  fully  implement  the  concept. 

52.  Links  with  the  physical  system  through  new  technologies,  e.g.  RFID 

53.  Enables  electronic  data  mining  of  raw  data  behind  displayable  information 

54.  Potential  for  closer  integration  of  development  activity  in  the  product  support  phase 
through  the  use  of  data  exchanges 

55.  Quality  of  authoring  data  and  [reduced]  cycle  time  of  updates  to  data  after  conversion. 

56.  Reduced  support  costs  through  a  single  standard 

57.  Logistics  traceability,  the  'integration'  in  ILS 

58.  Standardization 

59.  A  tighter  logistical  environment  is  a  prime  benefit,  Configuration  control  of  data  is 
mandated  into  S1000D 
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60.  Common  software/infrastructure,  common  knowledge  base 

61.  Cost  effective  for  updates;  no  more  paper;  for  producing  documents,  focus  on  content  and 
not  on  shaping 

62.  Create  new  uses  of  the  S1000D  documentation:  efficient  upgrades,  I.T.  help 
documentation,  statistics,  use  returns 

63.  Universality  -  land/air/sea;  civil  &  military,  worldwide  use  ==>  mature  spec,  COTS 
products 

64.  Via  the  new  S3000L  and  S1003X  you  will  have  a  direct  connection  between  LSAR  and 
the  tech  pubs  and  learning  infonnation 

65.  Much  higher  data  quality 

66.  Standard  formats 

67.  Reduced  costs  of  data  sustainment 

68.  The  process  module  makes  a  great  fault  troubleshooting  tool  but  is  difficult  to  leam. 

69.  Potential  for  common/interchangeable  IETP  viewers;  strong  organization  supporting  the 
spec 

70.  Interoperability  between  services  and  FMS  partners  who  rely  on  joint  tech  data. 

71.  Improved  cross  service  data  sharing  —  V22,  C-130J,  F-35,  and  Army  vehicles  used  by 
other  agencies 
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